This appendix to the Computing Curricula 2001 report defines the knowledge domain that is likely to be taught in an undergraduate curriculum in computer science. The underlying rationale for this categorization scheme and additional details about its history, structure, and application are included in the full task force report. Because we expect the appendices to have wider circulation than the full report, the task force feels it is important to include in each appendix a summary of the fundamental concepts that are necessary to understand the recommendations. The most important concepts are outlined in the sections that follow.
The CS 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.
In updating the body of knowledge from the framework established in Computing Curricula 1991, the CC2001 Task Force has to take account of the fact that the computing discipline has expanded to such an extent that it is impossible for undergraduates to learn every topic that has at one time been considered fundamental to the discipline. The task force has therefore sought to define a minimal core consisting of that material that essentially everyone teaching computer science agrees is essential to anyone obtaining an undergraduate degree in this field. Material offered as part of an undergraduate program that falls outside the core is considered to be elective. By insisting on a broad consensus in the definition of the core, the task force hopes to keep the core as small as possible, giving institutions the freedom to tailor the elective components of the curriculum in ways that meet their individual needs.
In discussing the CC2001 recommendations during their development, we have found that it helps to emphasize the following points:
To give readers a sense of the time required to cover a particular unit, the CC2001 report must define a metric that establishes a standard of measurement. Choosing such a metric has proven difficult, because no standard measure 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. To dispel ny potential confusion, however, it is important to underscore the following observations about the use of lecture hours as a measure:
A summary of the body of knowledge -- showing the areas, units, which units are core, and the minimum time required for each -- appears as Figure A-1. The details of each area follow as separate sections.
The following links will take you to the individual descriptions of these areas:
Figure A-1. Computer science body of knowledge with core topics underlined
|
DS. Discrete Structures (43 core hours)
PF. Programming Fundamentals (38 core hours)
AL. Algorithms and Complexity (31 core hours)
AR. Architecture and Organization (36 core hours)
OS. Operating Systems (18 core hours)
NC. Net-Centric Computing (15 core hours)
PL. Programming Languages (21 core hours)
|
HC. Human-Computer Interaction (8 core hours)
GV. Graphics and Visual Computing (3 core hours)
IS. Intelligent Systems (10 core hours)
IM. Information Management (10 core hours)
SP. Social and Professional Issues (16 core hours)
SE. Software Engineering (31 core hours)
CN. Computational Science and Numerical Methods (no core hours)
|