A Revised Curriculum Framework
Robert Cupper, Allegheny College

Goals and Perspective

The goals for undergraduate programs in computer science need to provide the student with a solid academic underpinning to set the stage for the lifelong learning essential to positive career development

A Framework

Though most will agree with Newell, Perlis, and Simon [3], that computer science is the study "of the phenomena surrounding computers," at its heart, computer science is basically the study of algorithms, their creation, manifestation as computer programs, validation, and evaluation. Computer science education can be subdivided it into a number of interrelated, yet distinguishable, parts: introductory courses, the core, advanced courses, applications courses, a research component, and mathematical co-requisites.

The Introductory Courses

The introductory courses provide the framework and tool set upon which the programs are built. In addition to providing the foundation for the major and minor programs in computer science, these courses should include sufficient basic skills development and perspective to be of value to non-majors, non-minors, and students seeking breadth in their studies through distribution courses. To accomplish this, courses need to be designed so as to be accessible to all of these groups, yet retain the rigor essential for the beginning major or minor and basic skills development needed for success in fields as diverse from one another as economics and chemistry. There continues to be controversy as to whether the introductory courses ought to be programming courses, breadth-first, or even survey courses. My own perspective suggests breadth-first as most compatible with the liberal arts landscape. However, since computer science is fundamentally a study of algorithms, and computer programs are a manifestation of algorithms, programming is basic. Consequently, though perspective on the discipline is a most important component of the introductory courses both for students intending to concentrate their studies in computing and those seeking computing skills or distribution, its share of the courses must be balanced with the need for strong programming skills development. One way out of this dilemma is the inclusion of formal laboratory periods of 2 or 3 hours per week for each course in the introductory sequence.

In the end, students should emerge from the introductory course sequence with reasonably good programming skills, a sound understanding of data structures, and a good perspective on the extent and richness of the discipline. Students must have an ability to read and use existing program elements, such as objects, and understand something of the art of development of significant programming projects. However, programming "in the small" is a prerequisite to understanding, in any practical sense, large systems development. This suggests that care needs to be taken to assure that object-oriented and other software engineering techniques do not obscure the learning of basic programming skills. Finally, students must gain an appreciation for the fundamental importance and utility of discrete mathematics in the computing enterprise. Though topic selection and pedagogy are more important than choice of a particular programming language, my observation is that students are motivated by what they perceive to be the current language/technology (currently C++). In summary, the problems here are:

  1. Selecting the appropriate balance between teaching programming skills and what I have termed perspective on the discipline.
  2. Maintenance of student interest without sacrificing rigor. Compromising rigor in the introductory courses compromises the integrity of the entire program. We must continue to find ways to make these courses sufficiently interesting, relevant, and exciting to offset the work required to support an appropriate level of rigor.
  3. Integrating essential topics from discrete mathematics into the introductory sequence in a way that excites rather than discourages students. These questions are critical, especially where the pressure is on to maintain student numbers in order to support a department faculty of creditable size.

The Core

The core course sequence includes the material at the heart of the discipline. The contents of the core are not only prerequisite for the more advanced courses, but should contain the material essential for a person to be considered "educated" in computer science. At Allegheny, the core currently consists of four courses: Principles of Computer Organization, Programming Language Concepts, Theory of Computation and Formal Languages, and Analysis of Algorithms.

By this reckoning, the essence of the discipline might be characterized as half theory (or mathematically based) and half more pragmatic principles. Some would argue that the balance is too heavy on the side of the mathematical based topics. But it is the mathematically based principles that are the most fundamental in the sense of both undergirding the study of algorithms and standing the test of time. We desperately need to make this case more convincing to our students and our classroom work more interesting and exciting.

What should be in the core is, of course, a difficult question. The members of the Liberal Arts Computer Science Consortium have spent many hours working on just this issue. A proposal for revision of the "Model Curriculum" is forthcoming. Curriculum 91 [4] with its knowledge units proved to be so flexible as to provide too little guidance. The Denning Commission on the Core of Computer Science [1] presented something more like the extent of computer science than the core. We need a permanent group, with a rotating membership, to collect the wisdom and experience of our colleagues and issue periodic recommendations.

For example, is some of the material from operating systems, networks, parallel algorithms, and distributed computing of sufficient importance to be added to the core - and if so, how can we do it, i.e., add a course, or remove existing topics, and in the latter case, which ones? In summary, the problems here are:

  1. What is the core of computer science; that is, what is the essence of the discipline that every educated computer scientist should know?
  2. How many courses are needed to include the topics that make up the core?
  3. Assuming that our discipline is still maturing, how do we maintain the proper and timely list of topics to include in the core?

Advanced Courses

Any creditable (major) program in computer science must go beyond the core. There are basically two directions this extension may follow - advanced courses and applications courses. The advanced courses provide for a deepening of knowledge/skills connected to, but built on the core. Advanced courses might include: Computer Architecture, Compiler Design, Operating Systems, and Software Engineering.

Though it is clear that some advanced course work ought to be part of the curriculum, it is not as clear how much or what part. But some advanced topics are more important than others and perhaps ought to be required. The questions here are:

  1. How many advanced courses should be required?
  2. Should particular advanced courses be required, or should those required be treated as electives?

Applications Courses

A significant portion of today's computer science students are interested in applications of computer science. That is, courses such as: Numerical Analysis, Artificial Intelligence, Database Systems, and Computer Networks

As is the case for advanced courses, the question here is how many, if any, applications courses ought to be required. Clearly, there needs to be room in the curriculum requirements to allow students to select some study of applications. A department's selection of the variety and type of applications courses may have a great deal to do with its attractiveness, and consequently, viability. The questions here are:

  1. How many, if any, applications courses should be required?
  2. Should any particular applications courses be required?
  3. Should a computer science major be permitted to choose an "applications path" - i.e., one that follows the core with applications courses and no advanced courses?

Research

The career paths of our students divide roughly into three groups: graduate study and research, industry, and other. Success in the first requires an ability to do research in computing. To this end, the educational process must include a research component. In this component, the student learns what research in computing is, and how to design, propose, and carry out a research project. In the second case, success in a career in industry requires leadership ability in the conception, design, and execution of rather large computing projects. Similar skills are required in either case - problem identification, specification of methods of approach, project proposal preparation, scheduling the work, successful navigation through the rough patches, completing the work, and reporting and defending the final product or result. This suggests that some portion of the curriculum specifically address these needs. One approach, that taken at Allegheny, is a capstone senior project or research thesis. This element of the curriculum consists of a seminar on topics and research methods in computing taken in the junior year followed by a two-semester senior project or thesis "course." Each student is required to complete a project/thesis as a part of the requirements for graduation.

The questions here are:

  1. How can we explicitly teach leadership, project planning, and research skills to our students?
  2. Is it appropriate to require a senior project/thesis of every computer science major? (After nearly 20 years of doing so, I would argue "yes!")

Mathematical Co-Requisites

The importance of certain mathematical foundations to computer science is well accepted. However, it remains arguable how much and what particular mathematics courses are needed. The raison d'etre for the mathematics co-requisite divides into two categories: specific topics and methods needed as pre and co-requisites for computer science courses and the general methodology of mature mathematical reasoning. Beyond some basic facility, such as calculus and discrete mathematics, the requirement should have at least some flexibility according to the mission of the program and the future plans and goals of the student. One of the greatest challenges that we face is that many of our students resist the mathematics requirements - both the specific mathematics courses required and the mathematically based core computer science courses.

The questions here are:

  1. What is the minimal mathematics required for a creditable computer science education?
  2. What is the optimal mathematics required?
  3. Should we allow an alternate "track" with no, or minimal mathematics required?

The Computer Laboratory

Computer science is, and always has been, a laboratory science. As in the case of the traditional natural sciences, this is true in two senses. First, the laboratory component of the curriculum is the arena for skills development - in our case, problem solving, programming, and systems development skills. Second, the laboratory is the facility for experimentation. Computing hardware and software have become so complex as to be mathematically intractable. Hence, in computing, as in the other natural sciences, it is necessary to formulate hypotheses and conduct laboratory experimentation to analyze the behavior of these components. The scientific method is an integral part of computer science education and must be included in our curricula. More computer science "labs" need to be designed to teach and exercise these skills. For both of these reasons, most courses in the curriculum should require weekly formal laboratory sessions.

Team Projects

Much of the work in computing, as in the other sciences, takes place in groups or teams. Consequently, it would be remiss to ignore this fact in the computing curriculum. Therefore, we must teach person-person interaction as well as person-computer interaction and provide some vehicle for practice or exercise. The laboratory sessions attached to the courses provide that vehicle. At minimum, team projects should be required in a number of courses selected from the required courses in the curriculum. Fair evaluations should expose students to the kinds of evaluations used for team members on the job "in the real world."

Summary

Computer science education, in my judgment, is at a crisis point. The discipline is beginning to mature, and those of us who are a part of the computer science education establishment must, and will, one way or another, decide the questions of topics and level of skills development, pedagogy, and rigor that were enumerated here. These are important issues for if we do not succeed in devising attractive yet rigorous programs, students interested in computing will go elsewhere and then enter positions in computing based on inadequate educational backgrounds with consequences for both themselves and society. Our task is made more difficult by the accessibility of today's computers and systems, encouraging a sense of over-confidence of those lacking the kind of formal training in computing detailed here. In addition, the pervasiveness of grade inflation, competition among departments for students, the mathematics "problem" referred to above, and current student's impatient need for relevance all serve to make our mission more challenging.

References

  1. Denning, P., D. Comer, D. Gries, M. Mulder, A. Tucker, A. Turner, and P. Young, "Computing as a Discipline." Report of the ACM Task Force on the Core of Computer Science, ACM Press, New York, 1988. Portions reprinted in Communications of the ACM 32,1 (January 1989), 9-23 and Computer 22, 2 (February 1989), 63-70.
  2. Gibbs, N., and A. Tucker (eds), "A Model Curriculum for a Liberal Arts Degree in Computer Science," Communications of the ACM, 29, 3 (March 1986), 202-210.
  3. Newell, A., A. Perlis, and H. Simon, "Computer Science," Science, 157 (1967), 1373-1374.
  4. Tucker, A. (ed), B. Barnes, R. Aiken, K. Barker, K. Bruce, J. Cain, S. Conry, G. Engel, R. Epstein, D. Lidtke, M. Mulder, J. Rogers, E. Spafford, and A. Turner, Computing Curricula 1991, ACM/IEEE-CS Joint Curriculum Task Force, ACM Press and IEEE-CS Press, New York, 1991. Portions reprinted in Communications of the ACM 34, 6 (June 1991), 68-84 and IEEE Computer 24, 11 (November 1991), 56-66.