Computing Curricula 2001
Computer Science Volume
Appendix B
Course Descriptions
This appendix to the Computing Curricula 2001 report consists of a set of course descriptions intended to serve as models for institutions offering undergraduate degrees in computer science. Although some institutions will presumably follow these models with little modification, the course designs presented here are intentionally designed to be flexible, allowing individual institutions to customize them to fit their own needs.
In most cases, the courses described here are similar to those already offered at the undergraduate level. The CC2001 Task Force sought to identify and document successful practice rather than to create entirely new models. While we encourage the development of innovative curricular strategies and experimental courses, we recognize that course design requires considerable time and in-class assessment that cannot be done effectively by committee. The model courses in this appendix are therefore best regarded as a common starting point for experimentation. While each course is presented in enough detail to be usable as it stands, institutions and individual faculty are encouraged to adapt and extend these courses as part of the dynamic process of curriculum develoment.
Fundamental concepts
The rationale behind the CC2001 curriculum is outlined in the full report of the task force. The appendices, however, are likely to have wide circulation and will certainly be read by many who do not have time to study the full report. For this reason, the task force has chosen to include in each appendix a summary of the fundamental concepts that are necessary to understand the recommendations. The most important concepts for understanding the course descriptions are as follows:
- The CS body of knowledge. The courses described in this appendix are defined in relation to a general taxonomy of that portion of computer science appropriate for an undergraduate curriculum. That taxonomy represents the body of knowledge for computer science. The body of knowledge is organized hierarchically into three levels. The highest level of the hierarchy is the area, which represents a particular disciplinary subfield. Each area is identified by a two-letter abbreviation, such as OS for operating systems or PL for programming languages. The areas are broken down into smaller divisions called units, which represent individual thematic modules within an area. Each unit is identified by adding a numeric suffix to the area name; as an example, OS3 is a unit on concurrency. Each unit is further subdivided into a set of topics, which are the lowest level of the hierarchy. The complete set of areas, units, and topics is specified in Appendix A.
- Core and elective units. Given the expanding scope of the computing discipline, it is impossible to insist that every undergraduate learn all the topics that were at one time considered fundamental to the field. The CC2001 Task Force has therefore sought to define a minimal set of core units for which there is a broad consensus that the material is essential to anyone obtaining an undergraduate degree in computer science. Because the core is defined as minimal, the core alone cannot constitute a complete undergraduate curriculum. Every undergraduate program must include additional elective units from the body of knowledge, although the CC2001 report does not define what those units must be. These elective units will typically vary by institution, field of study, and the needs of the individual student.
- Introductory, intermediate, and advanced courses. The courses in this appendix are divided into three categories according to the level at which they occur in the curriculum. Courses designated as introductory are typically offered in the first year of a college or university curriculum. Courses listed as intermediate are usually offered in the second or third year and build a foundation for further study in the field. Courses designated as advanced tend to be taken in later years and focus on those topics that require significant preparation in the earlier coursework. While these distinctions are easy to understand in their own right, it is important to recognize that there is no necessary relationship between the notions of core and elective -- which apply to units in the body of knowlege -- and the level of the course. Although introductory and intermediate courses will certainly concentrate on core material, it is perfectly reasonable to include some elective material even in the earliest courses. Similarly, advanced courses will include some core material. These designations are independent and should not be confused.
- Hours. To give readers a sense of the time required to cover a particular unit, the CC2001 Task Force had to identify some metric that would provide at least a comparative assessment of time. Choosing such a metric proved difficult, because there is no standard measure that is recognized throughout the world. For consistency with the earlier curriculum reports, the task force has chosen to express time in hours, corresponding to the in-class time required to present the material in a traditional lecture-oriented format. Note that this time does not include the instructor's preparation time or the time students spend outside of class. As a general guideline, the time required outside of class is approximately three times the in-class time. Thus, a unit that is listed as requiring 3 hours will typically entail a total of 12 hours (3 in class and 9 outside). It is also important to keep in mind that the time associated with each unit represents the minimum number of hours required for adequate coverage, and that it is always appropriate to spend more time than the listed minimum.
Organization and format of the course descriptions
As described in the preceding section, the courses presented in this appendix are organized into three levels: introductory, intermediate, and advanced. The point of this division is to provide natural boundaries for defining implementation strategies. Chapter 7, for example, defines six distinct instantiations of the introductory curriculum; Chapter 8 outlines four thematic approaches to the intermediate courses, along with a set of hybrid strategies that combine elements from these approaches. The implementation strategies and their relationship in the curriculum are shown in Figure B-1.
Figure B-1. Course levels and implementation strategies
In general, it should be possible to use any of the introductory approaches and follow it up with any of the intermediate approaches, although doing so may require transition material to ensure that all core units are covered. The strategies and tactics required to ensure a successful transition are described in Chapters 6-8.
The names of the individual pedagogical approaches have been chosen so that each begins with a unique letter. This fact makes it possible to assign course numbers in a way that simultaneously encodes the level, area, and pedagogical approach, as illustrated in Figure B-2. In the example shown, the subscript at the end of CS226C indicates that this intermediate-level course is part of the compressed approach.
Figure B-2. Course numbering scheme
The format of each individual course description is shown in Figure B-3. The parts of the template that vary from course to course appear in boxes.
Figure B-3. Components of a course description
B.1 Introductory tracks
In the course descriptions that follow, the introductory tracks are arranged in the order in which they are presented in Chapter 7.
B.1.1 Imperative-first
The imperative-first approach offers two separate implementations: one that covers the material in three courses (CS101I-102I-103I) and one that uses a more traditional two-course sequence (CS111I-112I).
B.1.2 Objects-first
Like the imperative-first approach, the objects-first strategy is also divided into a three-course (CS101O-102O-103O) and a two-course implementation (CS111O-112O).
B.1.3 Functional-first
The functional-first approach exists only in the two-semester form. If the approach proves popular, it may be appropriate to consider a three-semester implementation.
B.1.4 Breadth-first
As outlined in Chapter 7, we propose two implementations of a breadth-first approach. The first is simply to include an overview course (CS100B) before a more conventional programming sequence. The second is to expand the introductory curriculum into a three-semester sequence (CS101B-102B-103B) so that there is time for the additional topics.
B.1.5 Algorithms-first
The algorithms-first approach exists only in the two-semester form. If the approach proves popular, it may be appropriate to consider a three-semester implementation.
B.1.6 Hardware-first
The hardware-first approach exists only in the two-semester form. If the approach proves popular, it may be appropriate to consider a three-semester implementation.
B.2 Other first-year courses
The courses in this section are arranged in numerical order.
B.3 Intermediate courses
Although the courses in this section are typically identified with thematic tracks -- topics, compressed, systems, and web-based -- the course numbers are unique. This property makes it useful to list these courses in numerical order. If the same course appears in more than one track, all appropriate suffixes are shown.
CS210{C,S,T,W}. Algorithm Design and Analysis
CS220{C,S,T}. Computer Architecture
CS221W. Architecture and Operating Systems
CS222W. Architectures for Networking and Communication
CS225{S,T}. Operating Systems
CS226{C,S}. Operating Systems and Networking
CS230{T,W}. Net-centric Computing
CS240S. Programming Language Translation
CS250W. Human-Computer Interaction
CS255{S,W}. Computer Graphics
CS260{S,T}. Artificial Intelligence
CS261W. AI and Information
CS262C. Information and Knowledge Management
CS270T. Databases
CS271S. Information Management
CS280T. Social and Professional Issues
CS290T. Software Development
CS291S. Software Development and Systems Programming
CS292{C,W}. Software Development and Professional Practice
B.4 Advanced courses
The CC2001 Task Force has decided not to include in the printed report full descriptions of the advanced courses unless those courses are part of one of the curricular tracks described in Chapter 8. Instead, we plan to create web pages for these courses, which will be accessible from the CC2001 web page. A list of the advanced courses we propose appears in Figure B-4.
Figure B-4. Advanced courses by area
B.5 Project courses
As we discuss in section 9.3, we believe that it is critical for all undergraduates to complete a significant team project as part of their undergraduate program. In some cases, this experience may be integrated into existing courses, such as those in software engineering. In other cases, however, it is appropriate to offer standalone project courses that allow students to integrate the many concepts and skills they have learned as undergraduates in the context of a significant project.
The curriculum descriptions in this report refer to two different implementations of a project course. The first is
which provides a one-semester capstone experience. The second is the two-semester sequence
CS491. Capstone Project I
CS492. Capstone Project II
which makes it possible for students to complete a much more ambitious project over the course of a full year.
The design of these courses will vary greatly from institution to institution. In some programs, the project course may include lectures, particularly if the earlier courses do not cover the full set of required units in the core. In any event, we expect that any project course will provide coverage of some of the material from the body of knowledge, as illustrated in the following table:
| HC1 | Foundations of human-computer interaction | 2 | core hours (of 6) |
| HC5 | Graphical user-interface design | 2 | hours |
| HC6 | Graphical user-interface programming | 2 | hours |
| SE1 | Software design | 4 | core hours (of 8) |
| SE2 | Using APIs | 3 | core hours (of 5) |
| SE3 | Software tools and environments | 3 | core hours |
| SE4 | Software processes | 2 | core hours |
| SE5 | Software requirements and specifications | 2 | core hours (of 4) |
| SE6 | Software validation | 3 | core hours |
| SE7 | Software evolution | 2 | core hours (of 3) |
| SE8 | Software project management | 3 | core hours |
| | Team management | 2 | hours |
| | Communications skills | 2 | hours |
Regardless of whether these topics are covered in lecture or are simply acquired in the completion of the work, the focus of the course must remain on the project, which gives students the chance to reinforce through practice the concepts they have learned earlier in a more theoretical way.
