Evaluation of the Model Curriculum in
Computer Science and Engineering
M. E. Sloan
Michigan Technological University
Introduction
Curriculum reports in computer science and engineering
have traditionally resulted from committees, working in
relative isolation. Once chosen, the members of such committees as the ACM Curriculum Committee on Computer
Science and the COSINE Committee have held meetings,
debated, occasionally consulted with resource people, and
then have published their results. Informal prepublication
reviews have occurred, but no formal, formative evaluation
of previous work in CSE curriculum has ever been published.
The Model Curriculum Subcommittee of the Computer
Society broke this precedent by deciding to submit their
report for evaluation by a broad spectrum of the CSE
community before publication. This paper reports the
results of the evaluation.
Procedure
Copies of the report together with a survey questionnaire
were mailed to 35 reviewers representing a cross section
of the professional community. The reviewers, who were
selected from industry, government, and academia, were
asked to rate 19 aspects of the report on a five-point scale.
In addition, they were asked for detailed narrative comments on individual parts of the report.
Despite the report's bulk-more than 200 pages worth19 of the 35 reviewers persevered and submitted their
comments for a response rate of 54%. The typical reviewer
submitted three or four pages of comments. Appendix A
lists the reviewers and their affiliations.
General comments
The consensus of the reviewers was overwhelmingly
positive. In fact, only one review was predominantly
negative; it is discussed at length later. While generally
praising the report, reviewers did criticize inconsistencies,
varying levels of description, and missing material; they
referred to the report as a working document. One reviewer
114
called the presentation "poor and lengthy." In addition,
the following major substantive issues were raised:
* The core curriculum should be given greater emphasis.
It should be presented first and should, in the words
of one reviewer, "drop out cleanly."
* Other courses needed for a complete BS curriculum
should be shown. One reviewer suggested extra courses
to meet requirements of the Engineers Council for
Professional Development (ECPD); they are shown in
Appendix B.
* Too many courses are oriented toward a PhD program,
rather than toward developing BS graduates for
industry.
* The report should be issued as a joint document with
ACM.
Other suggestions and criticisms concerned emphasizing
the rapidity of technological changes; showing different
implementations for different types of departments; including courses on data acquisition, simulation, numerical
analysis, real-time computing, and computers and society;
developing courses for a strong computer science and
engineering minor; reducing the number of prerequisites
and corequisites; defining terms; and recommending the
year in which each course should be taken. One reviewer
stated that each student should spend a significant amount
of time in programming, both operating systems and
applications. Another suggested identifying courses that
might be taught outside a computer science and engineering department, such as logic in a philosophy department,
to help smaller schools start a computer science and engineering program.
Report ratings
Since only eight reviewers completed the section in
which the 19 characteristics were rated (the rest choosing
to give only narrative comments) this section of the evaluation should not receive undue importance merely because
COMPUTER
it provides quantitative data while the rest gives only
qualitative data. The main intent here was to identify
relatively strong and weak aspects of the report to show
what improvements should get top priority before publication. Because there is no comparable data on other computer science and engineering curricula, such as those of
ACM or COSINE, this section was not intended to rate
the qualities of the report, either in an absolute sense or
relative to similar reports.
The averages for each category ranged from 3.25 (clarity
of report) to 4.17 (computer organization and architecture
courses). One reviewer gave consistently low marks,
whereas most others were close to the average, and none
was notably high. To show the effects of one extreme
reviewer in such a small sample, averages were also computed omitting his ratings. The range was from 3.57
(statements of instructional objectives) to 4.60 (computer
organization and architecture courses). Table 1 shows
both sets of averages.
Because of both the limited number of reviewers and
the limited range of average ratings, close attention to
minor differences between ratings may be misleading.
One useful division of responses to satisfy the goal of
identifying strong and weak areas is to classify the ratings
in three groups-high (4.00 and above), middle (3.50 to
3.86), and low (below 3.50). Within each group, the characteristics are listed in order of their average rating by
all reviewers (with ties resolved by their order without
the low reviewer).
High ratings. The top-ranked characteristics or topics
were computer organization and architecture courses,
depth of curriculum, digital logic courses, and quality of
core curriculum.
Three of these are course areas; they happen to be the
two most hardware-oriented areas and the core curriculum.
The fourth characteristic gives credit for the depth of the
proposed curriculum.
Middle ratings. Receiving middle ratings were quality
of writing style, software engineering courses, laboratory
courses, relation between lab and other courses, references,
implementability of core curriculum, breadth of curriculum,
bridge between hardware and software, organization of
report, and statements of instructional objectives.
Table 1. Report Ratings.
AVERAGE RATINGS
ALL BUT LOW
ALL
REVIEWERS REVIEWERS
TOPIC
(3.93)
3.56
BREADTH OF CURRICULUM
4.00
(4.43)
DEPTH OF CURRICULUM
3.29
(3.67)
IMPLEMENTABILITY OF CURRICULUM
4.00
(4.29)
QUALITY OF CORE CURRICULUM
3.57
(3.83)
IMPLEMENTABILITY OF CORE CURRICULUM
(3.86)
BRIDGE BETWEEN HARDWARE AND SOFTWARE 3.50
3.71
(3.83)
LABORATORY COURSES
(3.80)
RELATION BETWEEN LAB AND OTHER COURSES 3.67
4.00
(4.40)
DIGITAL LOGIC COURSES
COMPUTER ORGANIZATION AND
4.17
(4.60)
ARCHITECTURE COURSES
3.83
(4.20)
SOFTWARE ENGINEERING COURSES
3.33
(3.60)
THEORY OF COMPUTING COURSES
3.25
(4.00)
CLARITY OF REPORT
3.50
(3.86)
ORGANIZATION OF REPORT
(3.83)
3.43
PREREQUISITE STRUCTURE
(4.00)
3.57
REFERENCES
(3.57)
STATEMENTS OF INSTRUCTIONAL OBJECTIVES 3.50
3.86
(3.86)
QUALITY OF WRITING STYLE
(3.71)
3.38
CONSISTENCY OF WRITING STYLE
December 1977
Two course areas-software engineering and laboratory
-appear near the top of this group, suggesting that a
moderate amount of polishing and revising is needed.
Several other characteristics given middle ratings-quality
of writing, style, references, and organization of reportare primarily matters of style and can be improved with
minor smoothing and editing. The rating of references
reflects several areas with few or no references, a matter
of concern for the coordinators of those areas.
The remaining mid-ranked aspects-relation between
lab and other courses, implementability of the core curriculum, breadth of the curriculum, bridge between hardware
and software, and statements of instructional objectivesare substantive concerns that cannot be simply handled.
Improving the relation between lab and other courses
requires major coordination and perhaps reworking of
both types of courses. Improving implementability of the
core curriculum requires consideration of the needs and
resources of a wide variety of schools; it may well be that
in a time of limited educational resources no solid computer science and engineering core curriculum could be
implemented at many of these schools. The middle rating
of breadth of curriculum primarily results from a decision
of the model curricula committee to limit their initial
work to computer science and engineering courses, rather
than recommending entire undergraduate curricula. Per,
haps future work can consider the entire curriculum; this
aspect is discussed further later in this paper. The rating
for the bridge between hardware and software simply
means that the committee did not solve this problem-not
a surprising circumstance considering the results of other
attempts to bridge the gap. That the rating for combining
hardware and software is as high as it is is a tribute to the
committee. Finally, the borderline rating for statements
of instructional objectives results both from their uneven
quality and from their nature. Although some instructional
objectives can be rewritten for the published report,
changing all ttie objectives to behavioral objectives to
meet the standards of their advocates would require much
time.
Low ratings. The lowest ranked aspects of the report
were prerequisite structure, consistency of writing style,
theory of computing courses, implementability of curriculum, and clarity of report.
Just one of these-theory of computing courses-is a
subject area. It does not appear to have been rated low
primarily because of its faults. The reviewers showed
little interest in this area, giving fewer comments on theory
of computing than on any other area. The low rating may
result from this lack of interest in much the same way as
the operating systems report issued by the COSINE committee received relatively low ratings.
Implementability of the curriculum, like implementability
of the core, is largely a problem of resources and interests
of each institution. Some attention can be paid to suggestions for implementation, but little can be done given the
nature of the problem and the time before publication.
The remaining low ratings went to features of the report
that should be improved as much as feasible before publication. The prerequisite and corequisite structure can be
simplified. More attention can be paid to prerequisites, if
any, other than computer and science engineering courses,
such as mathematics, engineering, and physics courses.
Consistency of writing style and clarity of the report
should receive high priority. Clarity received the lowest
rating. It can be improved by sharpening focus, improving readability, striking redundant and irrelevant material,
providing overviews, and the like.
115
Core curriculum
The reviewers generally praised the core. They made
fewer comments on this section than on any other, except
for theory of computing, but the few comments they did
make were positive and constructive. As mentioned earlier,
they wanted to emphasize the core. Some commented that
the core was still fragmented and needed more cohesion;
they suggested identifying complete core courses.
According to one reviewer, "The core is the best part of
the report; it is practical and realistic. It can easily be
implemented within the framework of a typical EE program without accreditation problems. The sequencing
seems good."
Another said, "Core is good. There could be implementation problems because it seems comprehensive."
Digital logic subject area
The digital logic subject area with a rating of 4.00 received
few but positive comments. One reviewer called it "unexpectedly good," noting that "the balance of practical and
theoreticaris very good compared to classical logic courses."
Another said it was "quite well done." A third said that it
was adequate for today's engineering and computer science
graduates but needed to emphasize LSI for tomorrow's
graduates.
Reviewers offered more detailed comments on the individual courses. Those noted below and in the following
sections represent only substantive items of general
interest. Others, such as suggested references, identification of misprints, stylistic comments, and the like are left
to the individuals revising the report. Hence, the comments
here may be considered as suggestions to a course
instructor or as a minority report.
DL-1, Theory and Application of Switching Theory and
Logic Design I. This course and its successor, DL-2, had
perhaps the most detailed descriptions in the report. Some
reviewers liked this; one noted, "I was impressed by the
DL-1 course writeup and its level of detail." Another was
less sure; he said, "DL-1 and DL-2 seem good, if anything
too thorough." There were suggestions on content, such
as emphasizing LSI. One industrial reviewer said, "Industry uses timing analysis and time diagrams much more
than is found in conventional logic courses. I hope the
timing aspect can be emphasized in this course."
DL-2, Theory and Application of Switching Theory and
Logic Design II. The reviewers liked this course. One
noted briefly, "A nice course"; another supported the
desirability for such a course. The main suggestions for
content were to emphasize practical aspects, such as LSI
blocks. One reviewer wrote, "Two small items need more
emphasis: (a) an explicit study of inter-register transfer
mechanisms: gating structures, busses, MUX's; (b) hazards
in asynchronous circuits; a fundamental concept appearing
in all asynchronous systems."
DL-3, Microprocessor Systems. Many reviewers noted
that this course was less thoroughly prepared than the
preceding two; they suggested references, noting the
paucity of books available in late 1976. One reviewer
thought the course should be oriented toward "small computers," presumably including minicomputers. The reviewers disagreed on the treatment of bit-slice computers.
One thought that the module on microprocessor organizations should contrast bit-slice organizations to monolithic
CPU ones; another thought that bit-slice microprocessors
116
are really advanced logic devices and, as such, should be
treated in DL-2.
DL-4, Digital Logic Devices Technology. Engineeringminded reviewers were enthusiastic about this course,
characterizing it as "a great course" and "a good idea."
They tempered their enthusiasm with comments on the
need for a text. One reviewer thought that the discussion
of memory devices should include all IC types, CCD, bubble
memories, etc.
DL-5, Digital Design Automation. The reviewers had
primarily negative comments on this course. Two felt
strongly that the material should be left for a graduate
course, noting that the graduate who enters industry will
probably learn his employer's system. Others commented
on the lack of depth and quality of the course outlines.
One noted:
This is unfortunately a relatively sketchy outline of
a course which lists a number of subject items but
doesn't provide a very detailed description of them.
Totally lacking is coverage of manufacturing design
automation practice. What is missing is an overview
section showing the product development flow from
the engineering sketch to the mask generator or the
automatic test equipment, the latter two items being
used by manufacturing. The file structures to support
these diverse activities must be described along
with... the equipment and techniques used in both
engineering and manufacturing to build a product.
The present emphasis of DL-5 on the engineering
aspects of DA is too narrow. Perhaps a better description of each of the items listed in the course outline
would clear up my concerns in this area.
Another reviewer wrote:
DL-5 is very questionable. Is there really enough
organized knowledge here to justify a course? Certainly this is a very specialized topic that is not going
to be taught unless you can give more detail and
good references.
Computer organization and architecture subject
area
Although the reviewers rated this area the highest
(4.17), their comments were less than glowing. One was:
This series is well partitioned, but the organization
of the individual courses tends too well to reflect the
lack of basic theory and structure in the computer
-organization area. In particular, these courses seem
to degenerate into giving descriptions of machines.
A preferable approach is to analyze system (user)
requirements and then explore the time-cost tradeoffs in satisfying these requirements.
Another was:
There is too much fragmentation. For example,
courses CO-1, CO-2, CO-3, DL-3, C0-4 could, and
should, be offered as a single course or at most two
coordinated courses. An advanced system architecture course then could be offered which would
integrate operating systems, distributed processing,
networks, and advanced computer organization.
A more positive comment was:
The series on computer organization and architecture
looks very good. Again there is some variation in
the level of detail of the course descriptions but the
coverage is broad and inclusive.
CO-i, Introduction to Computer Organization. The
introductory course on computer organization was judged
to be lackluster, although few specific suggestions were
offered. As one reviewer put it, "The structure of this
COMPUTER
course has no particular appeal." One reviewer suggested
emphasizing the module on computer units; two suggested
combining this course with other computer organization
and logic courses.
CO-2, I/O and Memory Systems. In contrast to CO-1,
the reviewers were enthusiastic about a course on input/
output and memory. One noted:
I heartily endorse the identification of a requirement
for a separate course on I/O and memory. Interfacing is all too often neglected totally. I would
even further emphasize the need to carry this on
into the laboratory courses with attention there
being paid to such "mundane" issues an interfacing
various families of logic devices into an integrated
system. Too often degreed engineers are ill prepared
to get their hands dirty on these real world issues.
Another stated:
This can be a very useful course, but the outline is
pretty vague. Topics which need more emphasis
than is indicated are: (a) real-time constraints of I/O
devices, (b) buffering mechanisms, and (c) alternatives
in channel design.
CO-3, Computer Architecture. Reviewers thought the
outline of this course was weak and contained some questionable material. One thought that three credits instead
of four would be adequate and that CO-2 was not needed
as a prerequisite.
CO-4, Microprogramming. Reviewers felt strongly, both
pro and con, about this course. Some thought this topic
was too specialized for an undergraduate course; they
thought that parts of the course could be taught in the
digital logic sequence. Yet others liked the course, one
commenting that it was "quite well worked out." Several
commented on the need for up-to-date texts. Additional
topics suggested included control memory implementation
and microprogramming software aids.
CO-5, Distributed Processing and Networks. This course
was considered insufficiently developed for undergraduates
at this time. The apparent lack of course content and the
advanced references, including a 1976 PhD dissertation,
were evidence of the current inappropriateness of this
course for undergraduates.
Software engineering subject area
This area, rated 3.83 by the reviewers, attracted much
interest. Opinions seemed to be divided. One reviewer
stated,
Your software engineering courses do provide a
good bridge between what is regarded as computer
science in the liberal arts institutions and what we
would look upon as being computer engineering.
Another reviewer saw it differently:
The software engineering sequence is really not an
engineering approach to software. It appears mostly
to be a technique not a design course.
Other general comments included suggestions for additional courses-an advanced course in software engineering, advanced applications programming, program design,
and software methodology and practice. Presumably these
courses, suggested by four different reviewers, have much
in common.
SE-1, Introduction to Computing. This introductory
computing course was controversial. Some thought it
covered too much; others, too little. Some liked PL/I; others
did not. Representative comments follow:
December 1977
My major concerns deali primarily with the introductory courses in the SE sequence. I personally
feel that careful and precise expression of ideas in a
computer program is a sufficiently difficult task
that the first course should deal exclusively with
this issue. The use of a high-level language and the
hiding of all but the most essential details of the
underlying machine allow the student to spend his
time and energy formulating and implementing
good algorithms.
The course SE-1 is very poorly defined. If you try to
introduce three or four languages in an introductory
course, all you end up with is a confused student
who feels that programming is a very important
and complex task. Stick to one language (I like the
choice of PL/I). Develop the basics of computing
from a language-independent viewpoint and then
use the lab to teach the realization of algorithms,
using one programming language. There is very
little "meat" in the proposed course. This course
will probably have to be a service course that will
serve many other students besides those in the computer area.
It is my feeling that the instructional objectives,
with which I agree, are not supported by the course
outline. My own experience suggests that good
design and careful implementation of computer programs is sufficiently complex that other issues should
be excluded from the first course. Comparing calculators to computers and more than a superficial
treatment of basic computer components bring up
issues that higher level languages were intended to
hide. Internal representations of values, which is
highly machine-dependent, as well as the stress on
batch-oriented systems (in Module II), are particularly troublesome since -many students will receive
their first course in a time-sharing environment and
with languages that hide the internal representation
completely. The main thrust of the course should be
Module III. The careful analysis of the problem
before coding is started, in order to determine a
good algorithm, must be stressed. A large number
of short-to-medium scale problems, given out as each
new programming concept is introduced, can greatly
aid in a steady development of good programming
style.
I wouldn't recommend PL/I as an example programming language for freshmen; for an engineering
orientation, Fortran is fairly standard. PL/I is fairly
complicated. One can teach "analysis, design, documentation, implementation, and evaluation" with
Fortran.
SE-2.1.1, 2.1.2, and 2.1.3, Data Structures I, II, and III.
The reviewers, in a rare show of near-unanimity, thought
that three courses (9 credits) of data structures were too
much, at least for undergraduates. They recommended
that these courses (and possibly TC-1, Discrete Structures)
be consolidated into one or two courses.
One reviewer disagreed. He thought that Data Structures I attempted to cover too much material. He
recommended that an introductory data structures course
aim at familiarizing students with the most basic data
structure instead of mentioning esoteric structures. He
liked Data Structures II because it allowed the student
to apply the techniques of the earlier course to a serious
problem of meaningful depth.
Other recommendations included using an assembly
language and emphasizing data-base management, particularly indexed sequential files.
117
SE-2.2, Programming Languages. The main comments
on this course were that it should be interleaved with
SE-4, Translators and Translator Writing Systems. Several
reviewers wrote of their experiences in combining the
two courses. For example, one said:
Unfortunately the course on language translators
and TWS, SE-4, suffers from a very brief course
description. I have found that overlapping this
course with the one on programming languages,
SE-2.2, works quite well. By using two texts ... the
entire subject of language translator techniques,
including the writing of a fairly large compiler, can
be accomplished in two terms. The student emerges
somewhat battered but well aware of what is involved
in generating compilers.
One reviewer thought that the desc1iption of these two
courses confused the choice and evaluation of programming language features with implementation choices, such
as compilation techniques. Another thought the courses
should be preceded by one on program design.
SE-3.1 and 3.2, Operating Systems and Computer
Architecture I and II. Because of disagreement within
the Model Curriculum Subcommittee, two versions of these
two courses were presented-a standard version that
emphasized operating systems, and an alternative version
that stressed integration of the two topics. The reviewers
did not like this compromise. They felt that the committee should recommend one sequence or the other; however,
they too were divided on which one.
Speaking for the standard version, one reviewer commented:
This is the most carefully thought out and clearly
presented curriculum for courses in operating systems I have seen to date. It provides a unified
framework in which to present a wide body of
material. It provides both a theoretical base and a
large amount of practical material.
Another stated:
I want to discuss one final specific problem. I am
concerned about the wisdom of listing, on page 121,
"Alternate Operating Systems and Architecture
Course." I believe that the committee should decide
one course to recommend. It is then possible that
alternates, if appropriate, could be described in an
additional section on possible implementations. I
would note that the course defined on page 121 is
not nearly as well specified in its appearance as
other courses and this further detracts from it.
An advocate of the alternative sequence argues:
I am of the school that prefers to view the operating
system as an extension of the hardware architecture.
Hence, I feel that there must be a close tie-in
between courses in these areas . . . The alternative
series deserves up-front identification with pros and
cons clearly identified, and perhaps the model curricula should take a position on which is the "preferred"
approach. A macro look at the curricula does not
give any hints as to even the fact that there are
alternatives.
Another advocate of the alternative sequence argued:
I recommend the "combined" approach to operating
systems ... Some of the more theoretical aspects of
operating systems belong in a graduate-level course.
Also, I question any emphasis on teaching a student
how to "design" an operating system before he's
118
learned how to use one. I think that industry
would prefer the student learn how to cope with an
operating system first.
Still others felt the curricula unduly emphasized operating
systems. One wrote:
Too much emphasis is placed on operating systems.
Software engineering is concerned with the specification, design, and construction of software systems.
Students should have a broader contact with other
kinds of systems, e.g., data base management
systems (partly contained in Data Structures III),
systems for real-time process control, etc.
SE-4, Translators and Translator Writing Systems.
Most reviewers considered this course together with
SE-1.2.2. Independent comments were that the course
looked good and that the description was too brief.
Theory of computing subject area
As mentioned earlier, few reviewers provided specific
comments on the theory of computing area, which they
rated 3.33. They gave no general comments on the area.
TC-1, Discrete Structures. One reviewer said he felt this
should be a mathematics service course; however, it is
most commonly taught by computer science departments.
An industrial reviewer with some experience teaching a
similar course thought it covered too much material for
an undergraduate course without prerequisites. He suggested dropping the modules on groups and semi-groups,
lattices, and finite fields.
TC-2, Analysis of Algorithms. One reviewer suggested
emphasizing design, retitling the course "Design and
Analysis of Algorithms," and revising the course outline
correspondingly.
TC-3, Automata and Formal Languages. The only
reviewer to comment on this course suggested stressing
LR(k) and parsing much more to benefit computer'
engineers.
TC-4, Theory of Computing. No reviewer discussed this
course.
Laboratory sequence
The laboratory sequence, rated 3.71, received generally
favorable reviews. Comments ranged from "This program
is excellent," through "Courses are reasonable; some
descriptions are sketchy" to "Seems ok." Longer and
more philosophical comments included:
L-1 and L-2 seem reasonable, probably because this
sort of thing is already being done. The rest seem
like little more than suggestions as to things that
might be done. There is little here that is much help
in actually doing it.
The laboratory sequence is a well-planned sequence.
Its success will depend upon the teachers who put
together the experiments and projects and who tea'ch
the courses.
The laboratory program is an important part of any
curriculum. However, if there are too many, they
become "cookbook" type labs. One or two introductory labs should introduce students to the necessary
techniques. Later labs should be problem-solving
labs where the student must take on and solve one
COMPUTER
or at most two major problems during the semester.
The details about specific components, software, etc.
should be learned by going to references and reading.
This is what will be required after graduation.
L-1, Digital Lab. Reviewers thought this was "pretty
sketchy," especially considering the number and age of
ongoing laboratory courses on this topic. One reviewer
commented on the importance of this lab.
L-2 Minicomputer Lab. Reviewers considered this to be
an important lab. One, bucking the tide of existing labs
in this area, commented:
Logic Lab is not a necessary prerequisite. I think
Minicomputer Lab should teach computer organization, not assembly language and programming tools
(i.e., papertape, TTY, debugger, console). Therefore,
I don't like this outline.
L-3, Microprocessor Lab. Reviewers commented on the
sketchy description of this lab. One wrote, "There are
enough microprocessor labs around now that it ought to
be possible to come up with something more definite."
L-4, Digital Devices and Associated Components Lab.
The main comment on this lab is that it could be
reduced from two credits to one, given that D-4, Digital
Devices and Associated Components, is a corequisite.
L-5.1 and 5.2, Systems Design Laboratories. These labs
were considered to be too heavy on corequisites-two
courses for the first lab and three for the second.
Procedural issues
One reviewer was highly critical of the report. Most of
the substantive issues he raised have been noted earlier,
but he also raised several procedural issues that should
be considered in evaluating the report. He argued that
because the model curricula were not developed by a
"well-funded, broad-based group," the report should not
be issued without substantial refinement and additional
evaluation. In his words:
The development of a model curriculum which
attempts to set itself up as a standard for higher
computer engineering and science education in the
United States is a major undertaking which must
be done in a well-organized and well thought out
manner. Once such a model curriculum is published,
it can have a number of unintended influences upon
the discipline that it is trying to serve. Thus the
development of a model curriculum should be carried
out by a well-funded, broad-based group which has
considerable input from the people it purports to
serve.
In reading over the draft report, I quickly came to
the conclusion that the proposed curriculum does
not meet this important objective.
The committee working on this project is not, as far
as I know, well funded. It has had to draw upon
participants on the basis of their ability to fund their
own investment in this work ...
No major attempt has been made to obtain broad-
based inputs from those departments which actually
have a well-developed computer science or computer
engineering curriculum...
What is needed is a well-organized and carefully
selected group of experienced and respected professionals from the computer area to get together and
pull the report into a much more coherent form.
December 1977
The persons selected should not be limited to the
members of the current Task Force but should be
drawn from those engineering departments which
have extiisive experience in organizing and operating
undergraduate and graduate programs and from the
industrial area which are deeply involved at the
forefront of computer application and design.
If the IEEE Computer Society wishes to assume
the responsibility of defining a model curriculum,
then it should see that the funds are available
to insure that those persons selected in developing
the curriculum have the financial resources necessary
to meet and develop the curriculum. The curriculum
should then be circulated to the departments with
undergraduate computer programs for their comments and input. A final report then should be prepared which would better reflect the needs of an
undergraduate computer curriculum.
Future Plans
The reviewers were asked to recommend how frequently
the report should be updated and what additional areas
the committee should pursue. The reviewers thought that
the committee should update the report frequently;
suggestions ranged from yearly to every three or four
years. A representative comment was:
Curriculum review should be an ongoing activity at
all institutions of higher education. Updates may be
needed only rarely, but the need for an update should
be considered at least once every two years, and
preferably every year.
The reviewers thought a natural way to update the
report would be to get reactions of instructors who were
using it. One reviewer wrote:
It seems to me that the best way to update this
report would be to obtain feedback from people who
try to initiate or integrate portions of their curriculum
into their CSE programs. The problems that arise
when implementing a course or sequence of courses
as well as their solutions could be useful in updating
the model curriculum. Alumni of a model curriculum
could provide interesting comments on their education if a way could be found to obtain their comments.
Two major areas for future work emerged. Several
reviewers commented on the desirability of developing
a complete BS curriculum, showing mathematics, science,
engineering, and liberal arts courses, in addition to the
CSE courses discussed in this report. Engineering educators were concerned with curricula that would satisfy
ECPD guidelines.
The second area of interest was developing a CSE minor,
preferably drawing from courses proposed in the report.
One reviewer described the situation as follows:
One area this committee may look into is to develop
options to allow students in other areas to have a
strong CSE minor. The trend seemns to be that most
other fields will be utilizing computers for specialized
applications. Students need to acquire certain "CSE
skills." Courses like "applications of mini and micro
computers," together with microprocessor course
and lab, plus the basic introductory course, could
form a "strong" minor for a mechanical engineer
specializing in process control. A two-course sequence
in data management and data base design may be
excellent for students from business school. Furthermore, these courses will also be good for the CSE
majors as industry wants more professionally oriented graduates than academically oriented ones.
119
Appendix A. Reviewers
Julius A. Archibald, Jr., State University of New York,
Plattsburgh
Taylor L. Booth, University of Connecticut
Gerald L. Engel, Virginia Institute of Marine Science
Harlow Freitag, IBM
S. J. Garrett, University of South Florida
Hellmut Golde, University of Washington
Ellis Horowitz, University of Southern California
Glen G. Langdon, Jr., IBM
Georgia Marszalek, National Semiconductor
Richard E. Merwin, Department of the Army
Gerald R. Peterson, University of Arizona
Harriett B. Rigas, Washington State University
Alan B. Salisbury, Department of the Army
Henry D. Shapiro, Sperry Research Center
Merlin Smith, IBM
Robert W. Taylor, IBM
John F. Wakerly, Bell Northern Research
Terry Welch, Sperry Research Center
Raymond T. Yeh, University of Texas, Austin
Martha Evans Sloan is an assistant professor
in the Electrical Engineering Department at
Michigan Technological University, Houghton, 'Michigan. Her experience includes research in statistical communications theory
at Lockheed Missiles and Space Company,
Palo Alto, California; and teaching junior
mathematics and science at Frankfurt Inter-
national School, Oberursel, Germany.
Dr. Sloan, the Computer Society's treasurer
and a Governing Board member, is also chairman of the Education Committee's Survey Subcommittee, and a member of the
Education Committee, Model Curriculum Subcommittee, and
Technical Committee on Computer Architecture. She was guest
editor of the February 1975 special issue of the IEEE Transactions on Education and a recipient of the Dow Outstanding
Young Faculty Award of the American Society for Engineering
Education.
She received the BSEE, MSEE, and PhD degrees from Stanford University, in 1961, 1963, and 1973, respectively.
Appendix B. Suggested outline for electrical and
computer engineering curriculum to meet ECPD
guidelines for accreditation
I
Freshman
Chemistry
Physics
English
Communications
Math (analyt. & calc.)
Hum. & soc. science
Computers
Sophomore
Math (linear alg. & diff. eq.)
Economics
Hum. & soc. science
Physics
EE circuits and lab
Eng. science
Computers
EE (electronics)
EE adv. circuits
EE (elective)
Eng. science
Hum. & soc. science
Computers
Junior
Senior
Adv. hum. & soc. science
Adv. course in eng. or EE
Computer science, EE, or math electives
semester
hrs.
3
4
3
3
8
6
6
33
7
4
3
4
3
3
6
30
4
3
3
6
3
12
31
3
3
24
30
Semester hours for typical courses to meet ECPD guidelines
Humanities and social sciences
15-18 hr.
Physics
6-8 hr.
Chemistry
3-6 hr.
3 hr.
Communications,
Mathematics
15 hr.
Economics2
4 hr.
14 hr.
EE (required courses)
Engineering science'
6-9 hr.
60+
Computer science, EE, or mathi
IEngineering science could include thermo, statics, dynamics, transport
phenomena, fluids.
IEconomics is optional but required at some schools.
ISenior electives in computer science or electrical engineering should
include a design-oriented course. This could be satisfied by microprocessors.
120
COMPUTER