Cc2001

Computing Curricula 2001
Computer Science

— Final Report —
(December 15, 2001)

The Joint Task Force on Computing Curricula
IEEE Computer Society
Association for Computing Machinery

This material is based upon work supported by the
National Science Foundation under Grant No. 0003263

Composition of the Curriculum 2001 Joint Task Force
Vice-President, IEEE-CS Education Activities Board
Carl Chang
Chair, ACM Education Board
Peter J. Denning
IEEE-CS delegation
James H. Cross II (co-chair)
Gerald Engel (co-chair and editor)
Robert Sloan (secretary)
Doris Carver
Richard Eckhouse
Willis King
Francis Lau
Susan Mengel
Pradip Srimani
ACM delegation
Eric Roberts (co-chair and editor)
Russell Shackelford (co-chair)
Richard Austing
C. Fay Cover
Gordon Davies
Andrew McGettrick
G. Michael Schneider
Ursula Wolz

Endorsed by the ACM Council, November 2001
Endorsed by the IEEE-CS Board of Governors, December 2001

Executive Summary
This document represents the final report of the Computing Curricula 2001 project
(CC2001)—a joint undertaking of the Computer Society of the Institute for Electrical and
Electronic Engineers (IEEE-CS) and the Association for Computing Machinery (ACM)
to develop curricular guidelines for undergraduate programs in computing. The report
continues a long tradition of recommendations for academic programs in computing-
related fields dating back to 1965, as described in Chapter 2 of the report.
This volume of the report outlines a set of recommendations for undergraduate programs
in computer science. As described in Chapter 1, the CC2001 report will eventually
consist of several volumes containing separate recommendations for other computing
disciplines, including computer engineering, software engineering, and information
systems. Those reports are each under the control of separate committees and will be
published as they are completed.
Highlights of this report include the following:
• The CS body of knowledge. We have identified a body of knowledge appropriate to
undergraduate computer science programs. Drawing on the structure of earlier
curriculum reports, we have arranged that body of knowledge hierarchically,
subdividing the field into areas, which are then broken down further into units and
individual topics. An overview of the body of knowledge appears in Chapter 5.
• The CS undergraduate core. From the 132 units in the body of knowledge, we have
selected 64 that represent core material, accounting for approximately 280 hours of
instruction. As noted in our statement of principles in Chapter 4, we defined the core
as the set of units for which there is a broad consensus that the material is essential to
an undergraduate degree in computer science. The philosophy behind the definition of
the core is described in more detail in Chapter 5.
• Learning objectives. For each of the units in the body of knowledge, we have
developed a set of learning objectives designed to promote assessment of student
achievement. These learning objectives appear as part of the detailed description of
the body of knowledge in Appendix A. In addition to the individual learning
objectives, Chapter 11 of the report outlines a more general set of objectives that all
computer science graduates should be able to meet.
• Curriculum models. The report identifies six approaches to introductory computer
science that have proven successful in practice, as described in Chapter 7. Building on
that foundation, Chapter 8 offers a set of four thematic approaches for presenting the
core material in intermediate-level courses. The discussion of curricular models
continues in Chapter 9, which offers several models for the curriculum as a whole.
• Course descriptions. Appendix B contains detailed course descriptions for 47 courses
that are part of the various curriculum models. In addition, we have identified over 80
additional advanced courses that would be appropriate for undergraduate programs.
The process of developing the report has been highly inclusive. More than 150 people
have been directly involved in the focus groups established to contribute to the process.
In addition, the report has been widely reviewed by academics and practitioners through a
series of three public drafts. We have also held a series of feedback sessions at
conferences and meetings, including the Special Interest Group on Computer Science
Education symposium (SIGCSE), the Frontiers in Education conference (FIE), the World
Congress on Computers and Education (WCCE), along with various smaller meetings in
Europe, Asia, and various parts of the United States. These meetings have provided us
with critically important feedback, which we have used to shape the final report.

Table of Contents
Chapter 1. Introduction .......................................................................................................1
Chapter 2. Lessons from Past Reports ................................................................................6
Chapter 3. Changes in the Computer Science Discipline ...................................................9
Chapter 4. Principles .........................................................................................................12
Chapter 5. Overview of the CS Body of Knowledge........................................................14
Chapter 6. Overview of the Curricular Models.................................................................18
Chapter 7. Introductory Courses .......................................................................................22
Chapter 8. Intermediate Courses.......................................................................................35
Chapter 9. Completing the Curriculum.............................................................................40
Chapter 10. Professional Practice .....................................................................................55
Chapter 11. Characteristics of CS Graduates....................................................................62
Chapter 12. Computing across the Curriculum.................................................................67
Chapter 13. Institutional Challenges.................................................................................74
Acknowledgments.............................................................................................................78
Bibliography......................................................................................................................79
Appendix A. The CS Body of Knowledge .......................................................................83
Appendix B. CS Course Descriptions.............................................................................157

CC2001 Computer Science volume –1–
Final Report (December 15, 2001)

Chapter 1
Introduction
In the fall of 1998, the Computer Society of the Institute for Electrical and Electronic
Engineers (IEEE-CS) and the Association for Computing Machinery (ACM) established
the Joint Task Force on Computing Curricula 2001 (or CC2001 for short) to undertake a
major review of curriculum guidelines for undergraduate programs in computing. The
charter of the task force was expressed as follows:
To review the Joint ACM and IEEE/CS Computing Curricula 1991 and develop a revised
and enhanced version for the year 2001 that will match the latest developments of
computing technologies in the past decade and endure through the next decade.

As indicated in our charter, the goal of the CC2001 effort is to revise Computing
Curricula 1991 so that it incorporates the developments of the past decade. That task has
proved much more daunting than we had originally realized. Computing has changed
dramatically over that time in ways that have a profound effect on curriculum design and
pedagogy. Moreover, the scope of what we call computing has broadened to the point
that it is difficult to define it as a single discipline. Past curriculum reports have
attempted to merge such disciplines as computer science, computer engineering, and
software engineering into a single report about computing education. While such an
approach may have seemed reasonable ten years ago, there is no question that computing
in the 21st century encompasses many vital disciplines with their own integrity and
pedagogical traditions.

1.1 Overall structure of the CC2001 series
In light of the broadening scope of computing—and because the feedback we received on
our initial draft strongly encouraged us to move in this direction—we have chosen to
divide the CC2001 report into several volumes. This volume focuses specifically on
computer science. To encompass the many other disciplines that are part of the overall
scope of computing and information technology, however, IEEE-CS and ACM have
created additional committees to undertake similar efforts in other areas, including
computer engineering, software engineering, and information systems.
Once the individual reports have been completed, representatives from all the disciplines
will come together to produce an overview volume that links the series together. That
overview volume will contain definitions of the various computing disciplines along with
an assessment of the commonalities that exist in the curricular approaches. The structure
of the series as a whole is illustrated in Figure 1-1.

1.2 Overview of the CC2001 process
Developing the recommendations in this volume is primarily the responsibility of the
CC2001 Task Force, the members of which are listed at the beginning of this report.
Given the scale of the CC2001 project and the scope over which it extends, it was
necessary to secure the involvement of many other people, representing a wide range of
constituencies and areas of expertise. To ensure the broad participation necessary for
success in a project of this kind, the task force established a total of 20 focus groups,
divided into two distinct categories: Knowledge Focus Groups (KFGs) and Pedagogy
Focus Groups (PFGs).

Figure 1-1 Overall structure of the CC2001 report

The overview document will be produced by
representatives of the various disciplines after
the individual reports are complete. It will These reports—perhaps with additional
focus on computing education as a whole. volumes for other disciplines—will be
Computing Curricula 2001 prepared in consultation with existing
This report (which you are reading curriculum committees in these areas.
now in draft) will be published in In many cases, these committees have
2001 by the CC2001 Task Force. Overview already published curriculum guidelines
that can easily be incorporated into the

CC2001 structure.
CC2001 Computer Science volume

A separate committee has been
established to prepare the volume The Joint Task Force
on Computer Engineering. on Computing Curricula

IEEE Computer Society
Association for Computing Machinery

Computing Curricula 2001 Computing Curricula 2001 Computing Curricula 2001 Computing Curricula 2001

Computer Science Computer Engineering Software Engineering Information Systems

The Joint Task Force The Joint Task Force The Joint Task Force on Association for Computing Machinery
on Computing Curricula on Computing Curricula Software Engineering Education Association for Information Systems
Project Association of Information
IEEE Computer Society IEEE Computer Society (SWEEP) Technology Professionals
Association for Computing Machinery Association for Computing Machinery
–2–

Note: This diagram represents our vision of the eventual structure of the CC2001 report. No official organizational endorsements have yet been obtained.


1.2.1 Knowledge focus groups (KFGs)
Early in its history, the CC2001 Task Force identified a set of 14 areas that together
represented the body of knowledge for computer science at the undergraduate level, as
shown in Figure 1-2. For each of these areas, the task force appointed a knowledge focus
group composed of people with expertise and teaching experience in that domain. The
charge to each KFG was to prepare a report on the area from which the task force could
assemble the complete CS body of knowledge. Additional details on this aspect of the
process appear in Chapter 5 and Appendix A.
1.2.2 Pedagogy focus groups
Although the knowledge area focus groups are essential in terms of defining the body of
knowledge in each subdiscipline, they are not in themselves sufficient. Because each
group looks at the field of computer science through a lens that reflects a particular
specialty area, the KFG structure does not encourage the development of a broad vision
of the curriculum that focuses on crosscutting themes common throughout the discipline.
To develop that more holistic perspective and to address a variety of questions that
transcend the boundaries of the individual subdisciplines, the CC2001 Task Force
established six pedagogy focus groups to consider curricular issues across computer
science as a whole. These groups are listed, along with their specific charges, in Figure
1-3.
The pedagogy focus groups were formed later in the process than the counterpart focus
groups examining the knowledge areas. The work of the pedagogy focus groups,
moreover, proved more difficult to carry out solely through electronic communication.
With the support of a generous grant from the National Science Foundation, the CC2001
Task Force was able to convene a face-to-face meeting of the pedagogy focus groups in
June 2000, which proved extremely valuable in developing the final reports.
1.2.3 Two-Year College Task Force
Following the release in early 2001 of a draft version of CC2001, the ACM Two-Year
College Education Committee formed a joint ACM/IEEE-CS task force whose purpose
was to formulate a parallel curriculum report for the two-year college setting. This task
force undertook a very detailed examination of the draft CC2001 guidelines, focusing on
the introductory computer science topics and associated learning objectives, the
mathematics content, and electives at the introductory level. The CC2001 report was
subsequently influenced by the work of the two-year college task force, and that work
provided the basis for parallel introductory course sequences that foster greater
compatibility between two-year and four-year curricula, thereby facilitating the transfer
process.

1.3 Structure of the CC2001 computer science report
This volume of the CC2001 report looks specifically at computer science. The main
body of the report consists of 13 chapters. Chapter 2 begins with a survey and analysis of

Figure 1-2. The 14 knowledge focus groups
Discrete Structures (DS) Human-Computer Interaction (HC)
Programming Fundamentals (PF) Graphics and Visual Computing (GV)
Algorithms and Complexity (AL) Intelligent Systems (IS)
Architecture and Organization (AR) Information Management (IM)
Operating Systems (OS) Social and Professional Issues (SP)
Net-Centric Computing (NC) Software Engineering (SE)
Programming Languages (PL) Computational Science (CN)


Figure 1-3. The six pedagogy focus groups and their charges
PFG1. Introductory topics and courses
a. Identify the goals of the first year of study.
b. Report on the strengths and weaknesses of the traditional programming-first approach.
c. Provide a short list of alternative approaches which have credibility in terms of meeting those goals.
d. Identify and/or develop one or more introductory course sequences that address the problem of dissimilar
preparation of incoming students, do not rely on terminal service courses to discriminate among the various
needs and backgrounds of students who are just beginning their undergraduate careers, and introduce
computer science as a mainstream discipline that forms part of the academic core for a broad population of
undergraduate students.
e. Present syllabi for a short list of options for the first year of computer science study that satisfy the goals in
point (a) and that can serve as models for colleges and publishers.

PFG2. Supporting topics and courses
a. Specify a set of educational goals outside of traditional computer science that support undergraduate
computer science education, such as mathematics, engineering, science, technical writing, public speaking,
economics, project management, and so forth.
b. Identify a minimal list of supporting topics deemed essential to any undergraduate computer science
curriculum regardless of the nature of the institution.
c. Present suggestions for additional supporting topics beyond that minimum that may vary depending on the
type of institution, the populations an institution serves, and the number of courses which the institution is
allowed to include in a program.
d. Develop specifications for one or more sets of non-CS courses that satisfy these goals.
e. Develop one or more models for satisfying some or all of these goals by integrating them into computing
courses.

PFG3. The computing core
a. Given the specification of the CS core as input, develop a small number of curricular models that satisfy the
core requirements. Each model should consist of a short list of courses (four or five courses beyond the
introductory year of study), which would be required of every computer science graduate and which would
be manageable by virtually every type of undergraduate program.
b. Develop at least one curricular model that is an alternative to the traditional approach of organizing
programs around artifacts (e.g., courses in compilers, operating systems, and the like). Such models will
consist of cross-cutting courses focused on fundamental concepts, principles, and skills.
c. Develop at least one curricular model that has the Internet as its unifying theme.

PFG4. Professional practices
a. Report on those aspects of professional practices that our graduates have (or should have) assimilated as a
result of current curricula.
b. Report on what we do and do not know about supporting effective education in those professional practices.
c. Report on how these needs can be integrated into courses in the curriculum.
d. Report on industrial and internship work and its relationship to the development of professional practices.
e. Report on other aspects of professionalism (including ethical, social, legal and moral issues) and their
relationship to the computer science curriculum.

PFG5. Advanced study and undergraduate research
a. Given the definition of the CS core, develop a specification of computer science education beyond the core
that is necessary and sufficient for a undergraduate degree in computer science.
b. Develop a specification of the characteristics of graduates who have earned a four-year undergraduate
degree.
c. Include a specification of courses in both traditional and nontraditional areas that may be important for
modern undergraduate CS curricula.
d. Report on undergraduate research, including an evaluation of various existing models.

PFG6. Computing across the curriculum
a. Articulate “the core of the core” relevant to all citizens and to various families of academic disciplines.
b. Plan and develop a proper curriculum development effort that will address rigorously the challenge of
computing curricula for non-CS majors, be appropriate to institutions other than traditional four-year
universities (such as two-year community colleges in the United States), appeal to those from other
computing-related disciplines, appeal to those academic disciplines that make significant use of computing.
c. Acknowledge that this is a crucial area but one for which we cannot unilaterally develop an adequate
solution.
d. Acknowledge that this group’s job is not to solve the problem but rather to plan, develop, and initiate a
process that can and will lead to a solution.


past reports, focusing most closely on Computing Curricula 1991. Chapter 3 outlines the
changes that have occurred in computer science since the publication of the CC1991
report and the implications that those changes have for curriculum design and pedagogy.
In Chapter 4, we articulate a set of principles that have guided the development of
CC2001 as we attempt to build on the strengths of our predecessors while avoiding some
of the problems observed in the earlier reports. Chapters 5 and 6 present overviews of the
computer science body of knowledge and the curriculum recommendations that are
examined in detail in the appendices. Chapters 7 and 8 describe the courses and
approaches we recommend at the introductory and intermediate levels of the curriculum,
respectively. Because these courses alone do not constitute a complete undergraduate
curriculum, Chapter 9 summarizes additional courses and topics that must be included as
part of the academic program. One important aspect of the complete curriculum involves
the study of professional practice, which is discussed in Chapter 10. In Chapter 11, we
outline a set of characteristics that define the successful computer science graduate.
Chapter 12 looks at the problem of teaching computer science and computing-related
skills to students in other disciplines. Finally, Chapter 13 offers strategic and tactical
suggestions for addressing the institutional challenges that affect the implementation of
this report.
The bulk of the material in the report appears in two appendices. Appendix A looks in
detail at the body of knowledge for undergraduate computer science. Appendix B
consists of full descriptions for the recommended courses that comprise the sample
curricula. We hope that providing both the body of knowledge and course descriptions
helps departments to create effective curricula more easily than using either of these
sources alone.


Chapter 2
Lessons from Past Reports
In developing this report, the CC2001 Task Force did not have to start from scratch. We
have benefited tremendously from past curriculum studies and are indebted to the authors
of those studies for their dedicated efforts. As part of our early work on Computing
Curricula 2001, we looked carefully at the most recent curriculum studies—particulary
Computing Curricula 1991—to get a sense of how those studies have influenced
computer science education. By identifying which aspects of the previous reports have
been successful and which have not, we hoped to structure the CC2001 report to
maximize its impact. This chapter offers an overview of the earlier reports and the
lessons we have taken from them.

2.1 Historical background
Efforts to design model curricula for programs in computer science and computer
engineering began in 1960s, shortly after the first departments in these areas were
established. In 1968, following on a series of earlier studies [ACM65, COSINE67,
SAC67], the Association for Computing Machinery (ACM) published Curriculum ’68
[ACM68], which offered detailed recommendations for academic programs in computer
science, along with a set of course descriptions and extensive bibliographies for each
topic area.
Over the next decade, computer science developed rapidly, to the point that the
recommendations in Curriculum ’68 became largely obsolete. During the 1970s, both the
ACM and the Computer Society of the Institute of Electrical and Electronics Engineers
(IEEE-CS) appointed committees to develop revised computer science curricula. In
1977, the Education Committee of the IEEE-CS published a report for programs in
computer science and engineering [EC77]. The Computer Society’s report was
significant in that it took a broader view of the discipline, incorporating more engineering
into the curriculum and bridging the gap between software- and hardware-oriented
programs. Responding to the pressures generated by the rapid development of the field,
the Computer Society updated its computer science and engineering curriculum in 1983
[EAB83]. The ACM Curriculum ’68 report was superseded by a much more
comprehensive Curriculum ’78, which had a substantial impact on computer science
education. Among its contributions, Curriculum ’78 proposed a standard syllabus for a
set of courses that encompassed the core knowledge of computer science as a discipline.
In the late 1980s, the Computer Society and ACM joined forces to undertake a more
ambitious curriculum review, which was published as Computing Curricula 1991
[Tucker91], hereafter referred to as CC1991. The CC1991 report was more
comprehensive than its predecessors, but took a different approach. Unlike Curriculum
’78 and the 1983 IEEE-CS report, each of which focused on identifying a standard
syllabus for individual courses, CC1991 divided the body of knowledge associated with
computer science into individual knowledge units. Each knowledge unit in CC1991
corresponds to a topic that must be covered at some point during the undergraduate
curriculum, although individual institutions have considerable flexibility to assemble the
knowledge units into course structures that fit their particular needs. The appendix of the
CC1991 report included 11 sample implementations that show how the knowledge units
can be combined to form courses and programs to serve a variety of needs.


2.2 Evaluation of previous curriculum efforts
The decision to produce a new curriculum report was driven primarily by the enormous
changes that have occurred in computer science over the past decade. At the same time,
there was also a perception among some computer science educators that CC1991 was
not as influential as some of its predecessors. Although CC1991 is certainly more
detailed, institutions have sometimes found it harder to adopt than Curriculum ’78 and
the IEEE-CS model curriculum in computer science and engineering.
In order to understand both the strengths and the limitations of CC1991, the task force
undertook an informal survey of computer science educators. We developed a short
questionnaire, which we then mailed to the chairs of all computer science departments in
the United States and Canada. We also made the questionnaire available more generally
through the World Wide Web, although the vast majority of the responses still came from
North America. A copy of the questionnaire appears in Figure 2-1.

Over 98 percent of the respondents—we received 124 responses through the web and
about 30 responses through regular mail—supported the concept of updating the CC1991
report. The survey responses also revealed the following general reactions:
• Knowledge units are often not as useful as course or curriculum designs. Although
many respondents indicated that they liked the concept of knowledge units as a
resource, there was strong sentiment for a greater emphasis on course design along
with the knowledge units. Our survey revealed that many institutions continue to work
with the curriculum models outlined in Curriculum ’78, largely because it included
specific course designs.
• There is strong support for a more concrete definition of a minimal core. CC1991
argues that all undergraduate programs in computer science should incorporate the
entire collection of knowledge units in the nine areas that comprise the common
requirements. If the area encompassing Introduction to a Programming Language is
included, the knowledge units in the common requirements account for 283 hours of
classroom time. As our discipline evolves, it is tempting to add new material to the
required set, thereby increasing the number of hours mandated by the curriculum. Our
survey revealed considerable support for the idea of identifying a smaller set of core
topics that would serve as a foundation for more advanced study. The areas and

Figure 2-1. Questionnaire to assess the impact of Computing Curricula 1991
1. Did you use CC1991 in any way in the past?
2. If you are a college or university teacher, do you know if your department ever
looked at or used CC1991?
3. If you answered yes to either question, how was it used, and what features of it were
helpful?
4. Do you think there is a need to create CC2001? Why?
5. CC1991 had 10 main content areas. Do you think any new areas should be added?
Any existing area deleted? Any existing area updated?
6. Do you believe CC2001 should provide guidelines about a minimal core? If so,
what would that core include?
7. Do you have any suggestion about the format? CC1991 was designed in terms of
knowledge units along with possible model curricula in terms of those knowledge
units.
8. Have you any other comments or suggestions for updating CC1991?


structure of the more advanced courses could vary markedly depending on the nature
of the institution, the academic program, and the needs and interests of individual
students.
• Curriculum reports should pay greater attention to accreditation criteria for computer
science programs. Accreditation was an important issue for many survey respondents
in the United States. It is important to note, however, that the structure of accreditation
has changed markedly with the new criteria proposed by the Accreditation Board for
Engineering and Technology (ABET) and the Computing Sciences Accreditation
Board (CSAB) [ABET2000, CSAB2000]. Under the new guidelines, programs will be
allowed much greater flexibility than they have enjoyed in the past but must provide a
coherent rationale for their curriculum and demonstrate that it meets its stated goals.
This report is designed not only to help institutions design their computer science
curriculum but also to assist them in the preparation of the underlying rationale they
need to meet the new accreditation criteria. We also hope that this report will prove
useful to accreditation bodies in other parts of the world.


Chapter 3
Changes in the Computer Science Discipline
As we enter the new millennium, computer science is an enormously vibrant field. From
its inception just half a century ago, computing has become the defining technology of
our age. Computers are integral to modern culture and are the primary engine behind
much of the world’s economic growth. The field, moreover, continues to evolve at an
astonishing pace. New technologies are introduced continually, and existing ones
become obsolete almost as soon as they appear.
The rapid evolution of the discipline has a profound effect on computer science
education, affecting both content and pedagogy. When CC1991 was published, for
example, networking was not seen as a major topic area, accounting for only six hours in
the common requirements. The lack of emphasis on networking is not particularly
surprising. After all, networking was not yet a mass-market phenomenon, and the World
Wide Web was little more than an idea in the minds of its creators. Today, networking
and the web have become the underpinning for much of our economy. They have
become critical foundations of computer science, and it is impossible to imagine that
undergraduate programs would not devote significantly more time to this topic. At the
same time, the existence of the web has changed the nature of the educational process
itself. Modern networking technology enhances everyone’s ability to communicate and
gives people throughout the world unprecedented access to information. In most
academic programs today—not only in computer science but in other fields as well—
networking technology has become an essential pedagogical tool.
The charter of the CC2001 Task Force requires us to “review the Joint ACM and
IEEE/CS Computing Curricula 1991 and develop a revised and enhanced version for the
year 2001 that will match the latest developments of computing technologies.” To do so,
we felt it was important to spend part of our effort getting a sense of what aspects of
computer science had changed over the last decade. We believe that these changes fall
into two categories—technical and cultural—each of which have a significant effect on
computer science education. The major changes in each of these categories are described
in the individual sections that follow.

3.1 Technical changes
Much of the change that affects computer science comes from advances in technology.
Many of these advances are part of a ongoing evolutionary process that has continued for
many years. Moore’s Law—the 1965 prediction by Intel founder Gordon Moore that
microprocessor chip density would double every eighteen months—continues to hold
true. As a result, we have seen exponential increases in available computing power that
have made it possible to solve problems that would have been out of reach just a few
short years ago. Other changes in the discipline, such as the rapid growth of networking
after the appearance of the World Wide Web, are more dramatic, suggesting that change
also occurs in revolutionary steps. Both evolutionary and revolutionary change affects
the body of knowledge required for computer science and the educational process.
Technical advances over the past decade has increased the importance of many curricular
topics, such as the following:
• The World Wide Web and its applications
• Networking technologies, particularly those based on TCP/IP

CC2001 Computer Science volume – 10 –

• Graphics and multimedia
• Embedded systems
• Relational databases
• Interoperability
• Object-oriented programming
• The use of sophisticated application programmer interfaces (APIs)
• Human-computer interaction
• Software safety
• Security and cryptography
• Application domains
As these topics increase in prominence, it is tempting to include them as undergraduate
requirements. Unfortunately, the restrictions of most degree programs make it difficult to
add new topics without taking others away. It is often impossible to cover new areas
without reducing the amount of time devoted to more traditional topics whose importance
has arguably faded with time. The CC2001 Task Force has therefore sought to reduce the
required level of coverage in most areas so as to make room for new areas. This point is
discussed further in Chapter 4.

3.2 Cultural changes
Computing education is also affected by changes in the cultural and sociological context
in which it occurs. The following changes, for example, have all had an influence on the
nature of the educational process:
• Changes in pedagogy enabled by new technologies. The technical changes that have
driven the recent expansion of computing have direct implications on the culture of
education. Computer networks, for example, make distance education much more
feasible, leading to enormous growth in this area. Those networks also make it much
easier to share curricular resources among widely distributed institutions. Technology
also affects the nature of pedagogy. Demonstration software, computer projection, and
individual laboratory stations have made a significant difference in the way computer
science is taught. The design of computer science curricula must take into account
those changing technologies.
• The dramatic growth of computing throughout the world. Computing has expanded
enormously over the last decade. For example, in 1990, few households—even in the
United States—were connected to the Internet. A U.S. Department of Commerce
study [NTIA99] revealed that by 1999 over a third of all Americans had Internet
access from some location. Similar growth patterns have occurred in most other
countries as well. The explosion in the access to computing brings with it many
changes that affect education, including a general increase in the familiarity of students
with computing and its applications along with a widening gap between the skill levels
of those that have had access and those who have not.
• The growing economic influence of computing technology. The dramatic excitement
surrounding high-tech industry, as evidenced by the Internet startup fever of the past
five years, has significant effects on education and its available resources. The
enormous demand for computing expertise and the vision of large fortunes to be made
has attracted many more students to the field, including some who have little intrinsic
interest in the material. At the same time, the demand from industry has made it
harder for most institutions to attract and retain faculty, imposing significant limits on
the capacity of those institutions to meet the demand.


• Greater acceptance of computer science as an academic discipline. In its early years,
computer science had to struggle for legitimacy in many institutions. It was, after all, a
new discipline without the historical foundations that support most academic fields.
To some extent, this problem persisted through the creation of CC1991, which was
closely associated with the Computing as a Discipline report [Denning89]. Partly as a
result of the entry of computing technology into the cultural and economic
mainstream, the battle for legitimacy has largely been won. On many campuses,
computer science has become one of the largest and most active disciplines. There is
no longer any need to defend the inclusion of computer science education within the
academy. The problem today is to find ways to meet the demand.
• Broadening of the discipline. As our discipline has grown and gained legitimacy, it
has also broadened in scope. In its early years, computing was primarily focused on
computer science. Over the years, an increasing number of fields have become part of
a much larger, more encompassing discipline of computing. Our CC2001 Task Force
believes that understanding how those specialties fit together and how the broadening
of the discipline affects computer science education must be a critical component of
our work.


Chapter 4
Principles
Based on our analysis of past curriculum reports and the changes in our discipline
outlined in the preceding chapters, the CC2001 Task Force has articulated the following
principles to guide our work:
1. Computing is a broad field that extends well beyond the boundaries of computer
science. A single report that covers only computer science cannot address the full
range of issue that colleges and universities must consider as they seek to address
their computing curricula. Additional reports in this series will be required to cover
other computing disciplines.
2. Computer science draws its foundations from a wide variety of disciplines.
Undergraduate study of computer science requires students to utilize concepts from
many different fields. All computer science students must learn to integrate theory
and practice, to recognize the importance of abstraction, and to appreciate the value
of good engineering design.
3. The rapid evolution of computer science requires an ongoing review of the
corresponding curriculum. Given the pace of change in our discipline, the process
of updating the curriculum once a decade has become unworkable. The professional
associations in this discipline must establish an ongoing review process that allows
individual components of the curriculum recommendations to be updated on a
recurring basis.
4. Development of a computer science curriculum must be sensitive to changes in
technology, new developments in pedagogy, and the importance of lifelong learning.
In a field that evolves as rapidly as computer science, educational institutions must
adopt explicit strategies for responding to change. Institutions, for example, must
recognize the importance of remaining abreast of progress in both technology and
pedagogy, subject to the constraints of available resources. Computer science
education, moreover, must seek to prepare students for lifelong learning that will
enable them to move beyond today’s technology to meet the challenges of the
future.
5. CC2001 must go beyond knowledge units to offer significant guidance in terms of
individual course design. Although the knowledge-unit structure used in CC1991
can serve as a useful framework, most institutions need more detailed guidance. For
such institutions, CC2001 will be effective only to the extent that it defines a small
set of alternative models—preferably between two and four—that assemble the
knowledge units into reasonable, easily implemented courses. Articulating a set of
well-defined models will make it easier for institutions to share pedagogical
strategies and tools. It will also provide a framework for publishers who provide the
textbooks and other materials for those courses.
6. CC2001 should seek to identify the fundamental skills and knowledge that all
computing students must possess. Despite the enormous breadth of computer
science, there are nonetheless concepts and skills that are common to computing as a
whole. CC2001 must attempt to define the common themes of the discipline and
make sure that all undergraduate programs include this material.
7. The required body of knowledge must be made as small as possible. As computer
science has grown, the number of topics required in the undergraduate curriculum
has grown as well. Over the last decade, computer science has expanded to such an
extent that it is no longer possible simply to add new topics without taking others


away. We believe that the best strategic approach is to reduce the number of topics
in the required core so that it consists only of those topics for which there is a broad
consensus that the topic is essential to undergraduate degrees. Coverage of the core
is not limited to introductory courses, but will extend throughout the curriculum. At
the same time, it is important to recognize that this core does not constitute a
complete undergraduate curriculum, but must be supplemented by additional
courses that may vary by institution, degree program, or individual student.
8. CC2001 must strive to be international in scope. Despite the fact that curricular
requirements differ from country to country, CC2001 is intended to be useful to
computing educators throughout the world. Although it will be strongly influenced
by educational practice in the United States, we will make every effort to ensure that
the curriculum recommendations are sensitive to national and cultural differences so
that they will be widely applicable throughout the world.
9. The development of CC2001 must be broadly based. To be successful, the process
of creating the CC2001 recommendations must include participation from many
different constituencies including industry, government, and the full range of higher
educational institutions involved in computer science education.
10. CC2001 must include professional practice as an integral component of the
undergraduate curriculum. These practices encompass a wide range of activites
including management, ethics and values, written and oral communication, working
as part of a team, and remaining current in a rapidly changing discipline. We further
endorse the position articulated in the CC1991 report that “mastery of the discipline
includes not only an understanding of basic subject matter, but also an
understanding of the applicability of the concepts to real-world problems.”
11. CC2001 must include discussions of strategies and tactics for implementation along
with high-level recommendations. Although it is important for Computing Curricula
2001 to articulate a broad vision of computing education, the success of any
curriculum depends heavily on implementation details. CC2001 must provide
institutions with advice on the practical concerns of setting up a curriculum by
including sections on strategy and tactics along with technical descriptions of the
curricular material.
As one would expect in any project of this scale, it is clear in retrospect that the CC2001
Task Force has been more successful in implementing some of these principles than we
have in others. We have, for example, been less successful in terms of producing an
international document than we had hoped. The structure of undergraduate degrees
varies enormously around the world, to the point that it is impossible to articulate a single
set of recommendations that would work throughout the world. Although we have
included in Chapter 9 examples of curricular implementations designed for use in other
countries, the structure of computing education in the United States has had a profound
impact on the report. Similarly, we were unable to get as much feedback and
involvement as we would like from industry. We do, however, see curriculum
development as an ongoing process and hope that companies can become more engaged
in the curriculum-development process with individual institutions.
At the same time, we believe that we have maintained our commitment to keeping the
size of the core to a manageable level that nonetheless ensures that graduates have a solid
foundation in the field. Moreover, we are confident that the material in Appendix A and
Appendix B will provide enough detail about the underlying material and the structure of
appropriate courses to be of value to curriculum planners throughout the world.


Chapter 5
Overview of the CS Body of Knowledge
In developing a curriculum for undergraduate study in computer science, one of the first
steps is to identify and organize the material that would be appropriate for that level. As
noted in Chapter 1, the CC2001 Task Force sought to accomplish this goal by convening
a set of knowledge focus groups, assigning to each one the responsibility of defining the
body of knowledge associated with one of the following areas:
Discrete Structures (DS)
Programming Fundamentals (PF)
Algorithms and Complexity (AL)
Architecture and Organization (AR)
Operating Systems (OS)
Net-Centric Computing (NC)
Programming Languages (PL)
Human-Computer Interaction (HC)
Graphics and Visual Computing (GV)
Intelligent Systems (IS)
Information Management (IM)
Social and Professional Issues (SP)
Software Engineering (SE)
Computational Science and Numerical Methods (CN)
Each of the knowledge focus groups submitted a report to the CC2001 Task Force, which
reviewed those reports to determine whether the recommendations made by that group
was appropriate in the context of the curriculum as a whole.

5.1 Structure of the body of knowledge
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.

5.1.1 Core and elective units
As discussed in Chapter 4, one of our goals in proposing curricular recommendations is
to keep the required component of the body of knowledge as small as possible. To
implement this principle, the CC2001 Task Force has defined a minimal core consisting
of those units for which there is a broad consensus that the corresponding material is
essential to anyone obtaining an undergraduate degree in this field. Units that are taught
as part of an undergraduate program but which fall outside the core are considered to be
elective.


In discussing the CC2001 recommendations during their development, we have found
that it helps to emphasize the following points:
• The core refers to those units required of all students in all computer science degree
programs. Several topics that are important in the education of many students are not
included in the core. This lack of inclusion in the core does not imply a negative
judgment about the value, importance, or relevance of those topics. Rather, it simply
means that there was not a broad consensus that the topic should be required of every
student in every computer science degree program.
• The core is not a complete curriculum. Because the core is defined as minimal, it does
not, by itself, constitute a complete undergraduate curriculum.
• The core must be supplemented by additional material. Every undergraduate program
must include additional elective topics from the body of knowledge. The CC2001
report does not define what those topics must be, as this additional work can and
should vary based on institutional mission, the areas of concentration offered by a
given institution, and individual student choice.
• Core units are not necessarily those taken in a set of introductory courses early in the
undergraduate curriculum. Although many of the units defined as core are indeed
introductory, there are also some core units that clearly must be covered only after
students have developed significant background in the field. For example, the task
force believes that all students must develop a significant application as some point
during their undergraduate program. The material that is essential to successful
management of projects at this scale is therefore part of the core, since it is required of
all students. At the same time, the project course experience is very likely to come
toward the end of a student’s undergraduate program. Similarly, introductory courses
may include elective units alongside the coverage of core material. The designation
core simply means required and says nothing about the level of the course in which it
appears.

5.1.2 Assessing the time required to cover a unit
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 any potential confusion, however, it is
important to underscore the following observations about the use of lecture hours as a
measure:
• The task force does not seek to endorse the lecture format. Even though we have used
a metric with its roots in a classical, lecture-oriented form, the task force believes that
there are other styles—particularly given recent improvements in educational
technology—that can be at least as effective. For some of these styles, the notion of
hours may be difficult to apply. Even so, the time specifications should at least serve
as a comparative measure, in the sense that a 5-hour unit will presumably take roughly
five times as much time to cover as a 1-hour unit, independent of the teaching style.
• The hours specified do not include time spent outside of class. The time assigned to a
unit does not include the instructor’s preparation time or the time students spend
outside of class. As a general guideline, the amount of out-of-class work 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).


• The hours listed for a unit represent a minumum level of coverage. The time
measurements we have assigned for each unit should be interpreted as the minimum
amount of time necessary to enable a student to achieve the learning objectives for that
unit. It is always appropriate to spend more time on a unit than the mandated
minimum.

5.1.3 Packaging units into courses
The structure and format of courses vary significantly from institution to institution and
from country to country. Even within the United States, some colleges and universities
use a semester system while others follow a shorter quarter system. Under either system,
there can be differences in the number of weeks in a semester, the number of lectures in a
week, and the number of minutes in a lecture.
For the purposes of this report, we assume that a course meets three times a week over
the course of a 15-week semester and that the individual class meetings run somewhere
between 50 minutes and an hour. This schedule is typical for a 3-credit semester course
in the United States. Given that some of the available time will be taken up with
examinations and other activities, we have assumed that 40 hours of lecture are available
over the semester. In addition, students are expected to devote three hours of time
outside of class for each in-class hour, which means that the total time that each student is
expected to invest 160 hours in each course. Other countries use different metrics for
expressing the expected level of work. In the United Kingdom, for example, a course
described in this report would correspond to 15-16 points under the Credit Accumulation
and Transfer Scheme (CATS).

5.2 Summary of the CS body of knowledge
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 5-1. The details of the body
of knowledge appear in Appendix A.


Figure 5-1. Computer science body of knowledge with core topics underlined
DS. Discrete Structures (43 core hours) HC. Human-Computer Interaction (8 core hours)
DS1. Functions, relations, and sets (6) HC1. Foundations of human-computer interaction (6)
DS2. Basic logic (10) HC2. Building a simple graphical user interface (2)
DS3. Proof techniques (12) HC3. Human-centered software evaluation
DS4. Basics of counting (5) HC4. Human-centered software development
DS5. Graphs and trees (4) HC5. Graphical user-interface design
DS6. Discrete probability (6) HC6. Graphical user-interface programming
HC7. HCI aspects of multimedia systems
HC8. HCI aspects of collaboration and communication
PF. Programming Fundamentals (38 core hours)
PF1. Fundamental programming constructs (9) GV. Graphics and Visual Computing (3 core hours)
PF2. Algorithms and problem-solving (6) GV1. Fundamental techniques in graphics (2)
PF3. Fundamental data structures (14) GV2. Graphic systems (1)
PF4. Recursion (5) GV3. Graphic communication
PF5. Event-driven programming (4) GV4. Geometric modeling
GV5. Basic rendering
AL. Algorithms and Complexity (31 core hours) GV6. Advanced rendering
AL1. Basic algorithmic analysis (4) GV7. Advanced techniques
AL2. Algorithmic strategies (6) GV8. Computer animation
AL3. Fundamental computing algorithms (12) GV9. Visualization
AL4. Distributed algorithms (3) GV10. Virtual reality
GV11. Computer vision
AL5. Basic computability (6)
AL6. The complexity classes P and NP IS. Intelligent Systems (10 core hours)
AL7. Automata theory IS1. Fundamental issues in intelligent systems (1)
AL8. Advanced algorithmic analysis IS2. Search and constraint satisfaction (5)
AL9. Cryptographic algorithms
AL10. Geometric algorithms IS3. Knowledge representation and reasoning (4)
AL11. Parallel algorithms IS4. Advanced search
IS5. Advanced knowledge representation and reasoning
AR. Architecture and Organization (36 core hours) IS6. Agents
AR1. Digital logic and digital systems (6) IS7. Natural language processing
AR2. Machine level representation of data (3) IS8. Machine learning and neural networks
IS9. AI planning systems
AR3. Assembly level machine organization (9) IS10. Robotics
AR4. Memory system organization and architecture (5)
AR5. Interfacing and communication (3) IM. Information Management (10 core hours)
AR6. Functional organization (7) IM1. Information models and systems (3)
AR7. Multiprocessing and alternative architectures (3) IM2. Database systems (3)
AR8. Performance enhancements IM3. Data modeling (4)
AR9. Architecture for networks and distributed systems IM4. Relational databases
IM5. Database query languages
OS. Operating Systems (18 core hours) IM6. Relational database design
OS1. Overview of operating systems (2) IM7. Transaction processing
OS2. Operating system principles (2) IM8. Distributed databases
OS3. Concurrency (6) IM9. Physical database design
OS4. Scheduling and dispatch (3) IM10. Data mining
OS5. Memory management (5) IM11. Information storage and retrieval
IM12. Hypertext and hypermedia
OS6. Device management IM13. Multimedia information and systems
OS7. Security and protection IM14. Digital libraries
OS8. File systems
OS9. Real-time and embedded systems SP. Social and Professional Issues (16 core hours)
OS10. Fault tolerance SP1. History of computing (1)
OS11. System performance evaluation
OS12. Scripting SP2. Social context of computing (3)
SP3. Methods and tools of analysis (2)
NC. Net-Centric Computing (15 core hours) SP4. Professional and ethical responsibilities (3)
NC1. Introduction to net-centric computing (2) SP5. Risks and liabilities of computer-based systems (2)
NC2. Communication and networking (7) SP6. Intellectual property (3)
NC3. Network security (3) SP7. Privacy and civil liberties (2)
NC4. The web as an example of client-server computing (3) SP8. Computer crime
NC5. Building web applications SP9. Economic issues in computing
NC6. Network management SP10. Philosophical frameworks
NC7. Compression and decompression
NC8. Multimedia data technologies SE. Software Engineering (31 core hours)
NC9. Wireless and mobile computing SE1. Software design (8)
SE2. Using APIs (5)
PL. Programming Languages (21 core hours) SE3. Software tools and environments (3)
PL1. Overview of programming languages (2) SE4. Software processes (2)
PL2. Virtual machines (1) SE5. Software requirements and specifications (4)
PL3. Introduction to language translation (2) SE6. Software validation (3)
PL4. Declarations and types (3) SE7. Software evolution (3)
PL5. Abstraction mechanisms (3) SE8. Software project management (3)
PL6. Object-oriented programming (10) SE9. Component-based computing
PL7. Functional programming SE10. Formal methods
PL8. Language translation systems SE11. Software reliability
PL9. Type systems SE12. Specialized systems development
PL10. Programming language semantics
PL11. Programming language design CN. Computational Science (no core hours)
CN1. Numerical analysis
Note: The numbers in parentheses represent the minimum CN2. Operations research
number of hours required to cover this material in a lecture CN3. Modeling and simulation
CN4. High-performance computing
format. It is always appropriate to include more.


Chapter 6
Overview of the Curricular Models
The body of knowledge presented in Chapter 5 does not by itself constitute a curriculum.
To be useful, the CC2001 report must also define detailed course implementations and
strategies for assembling the individual courses into a complete undergraduate
curriculum. This chapter presents a brief description of the overall philosophy behind the
proposed curricular models. The descriptions of the courses themselves appear in
Appendix B.

6.1 Overall structure of the model curricula
The courses described in this report are divided into three categories according to the
level at which they occur in the curriculum. Courses designated as introductory are
typically entry-level courses offered in the first or second year of a college or university
curriculum. Courses listed as intermediate are usually second- or third-year courses and
build a foundation for further study in the field. Courses designated as advanced are
taken in later years and focus on those topics that require significant preparation in terms
of 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 level of the course and the
notions of core and elective, which apply only to units in the body of knowledge.
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 sometimes include some core material. These
designations are independent and should not be confused.

6.2 Overview of the implementation strategies
The point of establishing the distinction among introductory, intermediate, and advanced
courses is to provide natural boundaries for selecting implementation strategies. This
report, for example, defines six distinct instantiations of the introductory curriculum and
four thematic approaches to the intermediate courses. These implementations and their
relationship in the structure of the curriculum as a whole are illustrated in Figure 6-1.
The idea behind this structure is to offer greater flexibility by making it possible to start
with any of the introductory approaches and then follow up that introduction with any of
the intermediate approaches.
Figure 6-1. Course levels and implementation strategies

Introductory Imperative Objects Functional Breadth Algorithms Hardware
courses first first first first first first

Intermediate Topic-based Compressed Systems-based Web-based
courses approach approach approach approach

Advanced Additional courses used to complete the undergraduate program
courses


6.3 Managing the transition between different strategies
Given that the implementation strategies adopt different approaches and cover different
material, it is difficult to make the various tracks directly interchangeable. To offer
institutions as much flexibility as possible, we have tried to eliminate significant
transition problems by adopting the following policies:
• We have established a set of expectations for the introductory approaches in the form
of a set of units and topics that each of those approaches must cover. The details of
this coverage are outlined in Chapter 7. Given these guidelines for the introductory
coverage, intermediate courses can always depend on a certain level of preparation for
students emerging from any of the introductory tracks. This definition of a common
background at the end of a student’s introductory work should also make it easier for
institutions to meet the needs of students transferring from other programs.
• Where possible, we have left unscheduled time in each course syllabus, both to give
instructors flexibility and to allow for the inclusion of transitional material.
• We have allowed the material covered at the various levels of the curriculum to
overlap to a certain extent. If an intermediate or advanced course depends on material
that is covered by some but not all of the introductory tracks, we have included explicit
coverage of that material in the follow-on course to ensure that all possible
combinations of strategies can be made to work.
6.4 Covering the core
As illustrated in Figure 6-1, a complete undergraduate curriculum consists of an
introductory phase to establish basic foundations for further study, an intermediate phase
to cover most of the core units in the body of knowledge, and additional advanced
courses to round out the curriculum. Institutions that adopt the CC2001 model will
typically begin by choosing an implementation for the introductory phase and an
implementation for the intermediate phase. In most cases, institutions will then adapt
each of these implementations to fit the particular characteristics of the institution, the
preferences of the faculty, and the needs of the students. In doing so, it is important to
ensure that the curriculum that results includes at least the minimum coverage specified
in the core of the body of knowledge. If specific core units are not included in the
introductory and intermediate phase, the institution must then ensure that students acquire
this material in advanced courses and set the requirements for graduation accordingly.
Beyond the coverage of the computer science core, institutions must ensure that students
acquire the necessary background in other areas, as described in Chapter 9.
Figures 6-2 and 6-3 show two examples of how to combine the courses from Appendix B
so that they cover the computer science core. The model in Figure 6-2 uses the
imperative-first implementation for the introductory phase and a traditional topics-based
model for the intermediate courses; the model in Figure 6-3 uses an objects-first
introductory strategy and the compressed approach for the intermediate level. Other
combinations will work as well. To help potential adopters determine whether a set of
courses covers the core, the CC2001 web site includes a curriculum worksheet
implemented as a Java applet.
The tables shown in Figures 6-2 and 6-3 also illustrate the importance of redundant
coverage in ensuring that the individual models are interchangeable. The final column in
each table shows the number of additional hours allocated to the various units under that
combination. The entry for PL3 (Introduction to language translation) in Figure 6-2, for
example, indicates that the two core hours assigned to this unit are included in both
CS112I and CS210T. Adopters choosing this pair of strategies could either leave the
coverage out of one of the courses, thereby making time for additional topics, or include
it in both to reinforce the students’ understanding of the material.


cture

g

ment
sues
putin

ence
ing
Figure 6-2. Coverage of core units

is

s
nalys

rchite

velop
am m

ystem

rof Is
tures

tellig
Com
ction
Imperative-first introduction

ject
Progr

hm A

re De
and P
Struc

ter A

ing S
Traditional topic-based approach

ial In

e Pro
bstra

ntric

ses
ompu
lgorit

ataba

oftwa
tro to

perat

et-ce

rtific
ata A

screte

pston
ocial
0 T. A

5 T. O

0 T. N

0 T. A

0 T. D

hours
0 T. C
1 I. In

0 T. S

0 T. S
2 I. D

0. Ca
5. Di
CS11

CS11

CS11

CS21

CS22

CS22

CS23

CS26

CS27

CS28

CS29

CS49

Extra
Total
DS1. Functions, relations, and sets 6 6
DS2. Basic logic 10 10
DS3. Proof techniques 9 3 12
DS4. Basics of counting 5 5
DS5. Graphs and trees 2 4 6 +2
DS6. Discrete probability 6 6
PF1. Fundamental programming constructs 9 9
PF2. Algorithms and problem-solving 3 3 6
PF3. Fundamental data structures 6 6 3 15 +1
PF4. Recursion 5 5
PF5. Event-driven programming 2 4 6 +2
AL1. Basic algorithmic analysis 2 2 4
AL2. Algorithmic strategies 6 6
AL3. Fundamental computing algorithms 2 4 6 12
AL4. Distributed algorithms 3 3
AL5. Basic computability 1 6 7 +1
AR1. Digital logic and digital systems 3 3 6
AR2. Machine level representation of data 1 3 4 +1
AR3. Assembly level machine organization 2 9 11 +2
AR4. Memory system organization and architecture 5 5
AR5. Interfacing and communication 3 3
AR6. Functional organization 7 7
AR7. Multiprocessing and alternative architectures 3 3
OS1. Overview of operating systems 2 2
OS2. Operating system principles 2 2
OS3. Concurrency 6 6
OS4. Scheduling and dispatch 3 3
OS5. Memory management 5 5
NC1. Introduction to net-centric computing 2 2
NC2. Communication and networking 7 7
NC3. Network security 3 3
NC4. The web as an example of client-server computing 3 3
PL1. Overview of programming languages 1 1 2
PL2. Virtual machines 1 1
PL3. Introduction to language translation 2 2 4 +2
PL4. Declarations and types 1 2 3
PL5. Abstraction mechanisms 2 1 3
PL6. Object-oriented programming 3 7 2 12 +2
HC1. Foundations of human-computer interaction 2 6 2 10 +4
HC2. Building a simple graphical user interface 2 2
GV1. Fundamental techniques in graphics 2 2 4 +2
GV2. Graphic systems 1 1
IS1. Fundamental issues in intelligent systems 1 1
IS2. Search and constraint satisfaction 5 5
IS3. Knowledge representation and reasoning 4 4
IM1. Information models and systems 3 3
IM2. Database systems 3 3
IM3. Data modeling 4 4
SP1. History of computing 1 1 2 +1
SP2. Social context of computing 3 3
SP3. Methods and tools of analysis 2 2
SP4. Professional and ethical responsibilities 3 3
SP5. Risks and liabilities of computer-based systems 2 2
SP6. Intellectual property 3 3 6 +3
SP7. Privacy and civil liberties 2 2 4 +2
SE1. Software design 2 2 2 4 10 +2
SE2. Using APIs 2 3 3 8 +3
SE3. Software tools and environments 1 2 2 3 8 +5
SE4. Software processes 2 2
SE5. Software requirements and specifications 1 2 2 5 +1
SE6. Software validation 1 1 3 5 +2
SE7. Software evolution 2 2 4 +1
SE8. Software project management 2 3 5 +2
39 39 39 35 33 21 19 10 17 16 29 24


ice
Pract
t
cture

Mgm
Figure 6-3. Coverage of core units

is

g
orkin
nalys

rchite
ming

v and
tures

edge
Objects-first introduction

Netw
gram

hm A

re De
ter A
Struc

nowl
Compressed approach

sign
O Pro

ompu
O De

lgorit

oftwa
S and

nfo+K
screte
1 O. O

2O. O

0 C. A

0 C. C

hours
6 C. O

2 C. S
5. Di

2 C. I
CS11

CS11

CS11

CS21

CS22

CS22

CS26

CS29

Extra
Total
DS1. Functions, relations, and sets 6 6
DS2. Basic logic 10 10
DS3. Proof techniques 9 3 12
DS4. Basics of counting 5 5
DS5. Graphs and trees 4 4
DS6. Discrete probability 6 6
PF1. Fundamental programming constructs 7 2 9
PF2. Algorithms and problem-solving 2 2 3 7 +1
PF3. Fundamental data structures 3 8 3 14
PF4. Recursion 2 3 5
PF5. Event-driven programming 2 2 2 6 +2
AL1. Basic algorithmic analysis 2 2 4
AL2. Algorithmic strategies 2 6 8 +2
AL3. Fundamental computing algorithms 3 3 6 12
AL4. Distributed algorithms 3 3
AL5. Basic computability 1 6 7 +1
AR1. Digital logic and digital systems 3 3 6
AR2. Machine level representation of data 3 3
AR3. Assembly level machine organization 9 9
AR4. Memory system organization and architecture 5 5
AR5. Interfacing and communication 3 3
AR6. Functional organization 7 7
AR7. Multiprocessing and alternative architectures 3 3
OS1. Overview of operating systems 2 2
OS2. Operating system principles 2 2
OS3. Concurrency 6 6
OS4. Scheduling and dispatch 3 3
OS5. Memory management 5 5
NC1. Introduction to net-centric computing 2 2
NC2. Communication and networking 7 7
NC3. Network security 3 3
NC4. The web as an example of client-server computing 3 3
PL1. Overview of programming languages 2 2
PL2. Virtual machines 1 1
PL3. Introduction to language translation 2 2
PL4. Declarations and types 2 1 3
PL5. Abstraction mechanisms 1 2 3
PL6. Object-oriented programming 8 4 2 14 +4
HC1. Foundations of human-computer interaction 1 4 2 7 +1
HC2. Building a simple graphical user interface 2 2
GV1. Fundamental techniques in graphics 2 2 4 +2
GV2. Graphic systems 1 1
IS1. Fundamental issues in intelligent systems 1 1
IS2. Search and constraint satisfaction 5 5
IS3. Knowledge representation and reasoning 4 4
IM1. Information models and systems 3 3
IM2. Database systems 3 3
IM3. Data modeling 4 4
SP1. History of computing 1 1
SP2. Social context of computing 3 3
SP3. Methods and tools of analysis 2 2
SP4. Professional and ethical responsibilities 3 3
SP5. Risks and liabilities of computer-based systems 1 2 3 +1
SP6. Intellectual property 3 3
SP7. Privacy and civil liberties 2 2
SE1. Software design 2 2 4 8
SE2. Using APIs 1 1 3 5
SE3. Software tools and environments 2 1 3
SE4. Software processes 2 2
SE5. Software requirements and specifications 1 3 4
SE6. Software validation 1 2 3
SE7. Software evolution 3 3
SE8. Software project management 3 3
Total core hours per course 38 40 39 35 33 40 29 40

Cc2001

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Cc2001

Ähnlich wie Cc2001 (20)

Cc2001