-A A +A

CS2013 Strawman Report-Chapters 1-5 (DEPRECATED)

30 posts / 0 new
Last post
sahami
CS2013 Strawman Report-Chapters 1-5 (DEPRECATED)
AttachmentSize
CS2013-Strawman-Chap1-5.pdf280.44 KB

The CS2013 Strawman Report comment period is now closed. Please see the CS2013 Ironman report for the latest CS2013 draft to comment on. Forum to comment on Chapters 1 to 5 of the CS2013 Strawman report. We ask that comments related to specific text in the report please specify the page number and line number(s) of the text being commented on. Line numbers are provided on the far left-hand side of the each page. Please note: Comments on individual Knowledge Areas should be posted in the respective Forum for the Knowledge Area being commented on (not here).

Ernest Davis
What math should a CS student know?
field_vote: 
0
Your rating: None

There is no systematic discussion of what math, other than discrete math, a CS major should know or when they're supposed to learn it, except that HCI has a specific "Statistical Methods for HCI" section. The other Knowledge Areas assume whatever knowledge of math is convenient to assume. For instance, Modelling and Simulation list "Linear programming and its extensions", "Differential equations: ODE's and PDE's", and "non-linear techniques" (p. 51 lines 90, 92, and 93).
Computational Science: Processing lists under "Learning Outcomes" (p. 52 lines 159-162)

6. Explain how data is represented in a machine. Compare representations of integers to floating point numbers. Describe underflow, overflow, round off, and truncation errors in data representations.
7. Apply standard numerical algorithms to solve ODEs and PDEs. Use computing systems to solve systems of equations

though these are hardly represented under the "topics". Graphics includes affine transformations and 3D to 2D coordinate transformation. Is it assumed that the student has taken linear algebra/ODE's/multi-variable calculus, or is assumed that the CS courses will teach as much of this material as is needed? In this long, very detailed document, the omission of any discussion of how the math is to be learned is very puzzling.

floappel
Characteristics of a CS Graduate
field_vote: 
0
Your rating: None

Chapter 3, pp. 20-21, lines 52-63

I propose the following revisions. My suggestions have been informed by Dianne Martin's Inroads March 2012 article.

7. Commitment to life-long learning and adaptability
Graduates of a computer science program should realize that the computing field advances at a rapid pace, and graduates must possess a solid foundation that allows and encourages them to maintain relevant skills as the field evolves. Specific languages and technology platforms change over time. Therefore, graduates need to realize that they must continue to learn and adapt their skills throughout their careers. To develop this ability, students should be exposed to multiple programming languages, tools, and technologies as well as the fundamental underlying principles throughout their education.

8. Commitment to Professionalism and Ethics
Graduates of a computer science program must understand the basic cultural, social, legal, and ethical issues inherent in the discipline of computing. They should understand their individual roles in this process and be knowledgeable about the interplay of ethical issues, technical problems, and aesthetic values that play an important part in the development of new computing systems. As future practitioners, they must be able to anticipate the impact of introducing a given product into a given environment, including the impact upon individuals, groups, and institutions. Future practitioners must understand the responsibility that they will bear, and the possible consequence of failure. They must understand their own limitations as well as the limitations of their tools.

adanyluk
Modifications to "Characteristics of Graduates"
field_vote: 
0
Your rating: None

Thank you for your suggestions. For the next draft we have done the following:

In "Commitment to life-long learning and adaptability" we have made the suggested changes.

In "Commitment to Professionalism and Ethics" we adopted many of your suggestions but chose not to incorporate the theme of "anticipating impact" as we were concerned that truly anticipating impact was not a realistic expectation.

cspradling
Characteristics of CS Graduate
field_vote: 
0
Your rating: None

Chapter 3, page 20, lines 38-43

I propose that we also incorporate creativity as a characteristic of computer science graduates as suggested below.

Creative Approaches to Problem-Solving
Graduates need to understand how to apply the knowledge they have gained to solve real problems, not just write code and move bits. They should also realize that there are multiple solutions to a given problem and that selecting among them is not a purely technical activity, as these solutions will have a real impact on people’s lives. Their solutions should be novel, contain value, and expose a broad range of possible solutions. Graduates also should be able to communicate their solution to others, including why and how a solution solves the problem and what assumptions were made.

adanyluk
Creativity
field_vote: 
0
Your rating: None

We agree that creativity is an important characteristic and intended that the text at the end of "Familiarity with Common Themes" would get at the idea of moving beyond the "usual".

We elected not to make your suggested change because we were concerned that as written, it implied novelty for novelty's sake. (There are many cases where one actually wants the "usual" or "standard" solution to a problem.) In the next draft, you'll see that we did make other changes to the text of the "Problem solving skills" paragraph and hope that you will find those appropriate and useful.

Tom Anderson
comments on 1-5
field_vote: 
0
Your rating: None

Positive: there’s been considerable progress since the last version in 2008. But you should go farther, faster.

Comments:

1) Need to have a better strategy for handling the split between the core and electives. The field is expanding rapidly, as you admit. That means that most of the material in an undergrad curriculum is in the elective set, yet this receives the least attention from the committee.

Just taking my own university as an example, we offer almost 2000 hours of instruction at the undergrad level, and if anything we’re on the low side among our peers. That means 75% of the undergraduate material we teach is outside the core; to read this document, it makes it seem as if a coherent undergrad program would offer only about 500 hours of core + electives.

As a start, you could list the # of hours of each elective topic that schools should offer students, just as a way of normalizing.

If your argument is that the focus of this should be on the core, I ask why? Most of a student’s undergrad program will be in electives (and increasingly in the future): do we have nothing meaningful to say about that portion?

Perhaps your argument is that you don’t want to be unfair to small schools. But a typical small (teaching) college with 5 CS faculty can cover 2000 hours of instruction without breaking a sweat (e.g., by cycling through electives on a two year schedule). You can weasel this in just the way you do with the outer core, by allowing schools to customize the percentages – here’s a list of topics that students should have access to; most schools won’t have 100% of these topics covered, but might have 50%.

Almost all schools require considerable depth of some sort beyond a core. Are there no recommended characteristics of such coverage? Why do we all seem to require it then?

2) The doc would benefit a lot from an index, for the inner core, outer core, and electives – that is, a list of concepts that students must master at graduation, should master, or should have the opportunity to master. It is very difficult to extract this from the document.

3) The doc would benefit a lot from having a set of target tasks for the inner and outer core. For example: should a student be able to write a simple, correct, concurrent program? I couldn’t tell where you stood. I can perhaps guess from the number of hours you’ve given to the topic of synchronization primitives (not enough).

Together, 2+3 would provide the basis for an exit exam: what should every student be able to do on graduation? This is not what should be taught, or how long it should be taught, but what should the students know and be able to do?

4) You’ve made progress reducing the core, but you should go farther. There is no point in covering a topic an inch deep – its better to leave it out. The examples here are numerous, but just to pick one – you have 20 required minutes allocated to multiprocessor cache coherence. Why? One gets the sense that you have a target list of topics – each of which is important -- that are too numerous for students to be required to master. So instead of admitting that fact, you fudge, and make familiarity with the topic as the goal/requirement. Where’s the evidence that works? I’d argue that a passing familiarity with technical topic x (for almost all values of x) is a pointless exercise. My point in #1 is to make it clear that a solid treatment of, say, cache coherence is a 10 hour endeavor, not a 20 minute one.

A particular danger is that faculty at schools will take your recommendations literally. As in “The ACM says we should require these topics of our majors, and most of these other topics.” And “We want to give our students maximum flexibility.” Therefore, “We should push all the required topics into the minimum number of courses, so we can require just those and leave the rest as electives.” Result: “A bunch of badly structured intro survey courses.” So there’s a real cost to leaving requirements in.

5) Although you’ve made progress in this direction, especially concerning security, more attention is needed to cross-cutting issues such as fault tolerance, performance, usability.

I completely echo the previous comment that much wider industrial participation in this effort would help a lot. As a reality check, in the areas I’m familiar with (systems, networking, operating systems, etc), my school does not require many of the things in your inner core, much less the outer core, for graduation. And yet, our students get hired by the leading companies. So there’s clearly a disconnect – are these topics really really essential, or are you just making that up?

scot
Organizational suggestion
field_vote: 
0
Your rating: None

Because of the "cross-cutting" knowledge areas it can be hard to tell where some particular knowledge unit appears. For example, I tried to figure out which topics were covered in our data structures course and algorithms course. I expected this material to come from AL. However, I found that many topics appeared elsewhere, particularly under SDF:

DFS, BFS (IS as well as AL)
Iterative and recursive traversal of data structures (SDF)
Divide and Conquer Strategies (SDF)
Arrays (SDF)
String Processing (SDF)
Stacks, Queues, Priority Queues, Sets and Maps (SDF)
Simple linked structures (SDF)
Computational Geometry (GV)

The situation would have been similar for a PL course and many other courses. It is good that the knowledge units and courses are different, but I spent a lot of time leafing through the report to discover where a particular topic was tucked away.

An index of topics and where they appear would be very useful.

lmeeden1
Liberal Arts Computer Science Consortium (LACS) Comments
field_vote: 
0
Your rating: None

In reviewing the CS2013 Strawman Proposal, there are many encouraging features that can work well in a liberal arts setting. We like the description of general attributes that CS graduates should achieve. Liberal arts emphasizes education for life rather than for a specific career, with the ultimate goal of producing graduates who can think effectively about CS and keep learning as the field evolves. We therefore deeply appreciate the focus on fundamentals over currently hot topics. The division of knowledge into Tier 1, Tier 2, and electives is clear, and the emphasis on learning outcomes and levels of understanding is helpful.

As was pointed out in the document A 2007 Model Curriculum for a Liberal Arts Degree in Computer Science, liberal arts institutions have some unique properties that affect the CS curriculum they offer. Students at such institutions typically take a broad range of courses in the first two years as part of an exploratory process to clarify their interests. This exploration draws students into computer science who may not have initially intended to major in the field, bringing diverse students and multiple perspectives into computing. However, it also requires flexibility in when students take courses, in prerequisite structures, and in program requirements. Flexibility is especially important at smaller institutions where faculty size constrains the variety and frequency of course offerings. Liberal arts schools often build cooperative bridges among disciplines to gain a richer intellectual environment, even when individual departments can offer only a modest number of courses. Finally, because of the broader focus of a liberal arts education, courses in a major typically constitute about 40% of a student’s undergraduate program and so the curriculum must fit into 10-12 courses.

In this context, majors draw on insights from many disciplines, but flexible CS programs cannot guarantee that every student will study a large core. Nor is exhaustive study of such a core necessary in order to “produce graduates who can think effectively about CS and keep learning as the field evolves.” We therefore suggest that Tier 1 be made smaller (by moving some topics to Tier 2) and that a higher fraction of Tier 2 be optional. These changes would enhance opportunities for liberal arts CS departments to meet the proposed guidelines using the flexibility and interdisciplinary strengths that are common in the liberal arts environment.

A key feature of the 2007 liberal arts curriculum was that it provided a detailed description of specific courses that could be offered to achieve a well rounded CS program using a total of 303 hours of instruction. As presented in the Strawman, CS2013 includes almost the same number of required hours (163 Tier 1 hours plus 142 Tier 2), but the proposal does not suggest that this material can be organized into a coherent 10-12 course major. The 305 hours identified in CS2013 count independent hours and thus serve a different purpose than the 303 hours of an integrated and coherent curriculum of the 2007 liberal arts curriculum.

Precisely because knowledge areas are not directly linked to courses, it will be vital that the next draft of CS2013 provide a wide variety of exemplar programs that manage to achieve the guidelines in different ways. Descriptions of specific courses that combine multiple knowledge areas in a coherent way will be especially important. It is not difficult to come up with 20 courses that cover the Tier 1 and Tier 2 topics, but it will take creativity to come up with 10-12 courses that cover most of these topics without “kitchen sink” courses that spend a few hours on each of a half dozen knowledge areas related only by the fact that they need to be covered somewhere.

Finally, the learning outcomes are generally valuable as concrete indications of how thoroughly students should master the topics within each knowledge unit; the “knowledge/application/evaluation” tags for outcomes notably help with this. However, there is considerable variation between and within knowledge units in the level of abstraction with which learning outcomes are expressed and how completely they cover the topics, and it is unclear whether all outcomes are equally essential (some seem intuitively less essential than others). The learning outcomes would be more useful if they were more uniform in abstraction and their relative importance were clearer—perhaps some prioritization could be added to help instructors determine which outcomes are fundamental and which are more periphery.

The following members of LACS have contributed to this response: Doug Baldwin, SUNY Geneseo; Alyce Brady, Kalamazoo College; Scot Drysdale, Dartmouth College; Max Hailperin, Gustavus Adolphus College; Deepak Kumar, Bryn Mawr College; Andrea Lawrence, Spelman College; Lisa Meeden, Swarthmore College; Takis Metaxas, Wellesley College; Rhys Price Jones, George Washington University; and Henry Walker, Grinnell College.

lkpresnell
Course Exemplars
field_vote: 
0
Your rating: None

On page 10, the inclusion of specific course exemplars in the Ironman draft is discussed. Please include courses from community colleges in these exemplars. Students attending a community college must transfer to a 4-year college, so courses taught at a community college typically transfer well to many different institutions. Therefore, such courses are often good examples for the first two years of a CS program.

alan_fekete
Bloom-lite terminology
field_vote: 
0
Your rating: None

I agree with the concern raied by Ray Lister in his SIGCSE Inroads piece http://dx.doi.org/10.1145/2189835.2189840
It is potentially confusing to use the terminology Knowledge, Application, Evaluation for the types of mastery expected in the outcomes, in the way that you do. Either use Bloom properly, or find other suggestive words. One possibility is to keep a three level classification, but do so by explicitly combining several Bloom levels at a time.

alan_fekete
breadth vs depth in the core
field_vote: 
0
Your rating: None

I disagree in large measure with the views expressed by Tom Anderson and A0110915, who suggest that it would be better to have less in the core but cover it more thoroughly. In particular, I think that a level of awareness of many active issues is important for all CS grads, but mastery is needed only for a few. For as concrete example mentioned by Tom: multiprocessor cache coherence. I think it is vital that every CS grad know that multiprocessors can have weird memory models, and that there is stuff happening to support the memory model that can be a huge impact on performance. That can be done in 15 minutes. Only a small subset of graduates will need to spend the 10 class hours to actually know how the coherence protocol works, and even fewer will need to either implement a coherence protocol or design a new one.

The learning outcome levels should make it clear what is the depth obtained in the core. One need for the curriulum document is to check that each such core topic has matching elective content that goes much deeper.

jose.contreras
About Learning Outcomes (LO)
field_vote: 
0
Your rating: None

it was not expected to have “Analysis” or “Comprehension” as LO types. I propose the following changes where they appear:

Page 69, line 37, change “comprehension” by “Application”
Page 69, line 39, change “comprehension” by “Knowledge”
Page 70, line 63, change “comprehension” by “Knowledge”
Page 71, line 118, change “comprehension” by “Knowledge”
Page 72, line 141, change “understand” by “identify” or “describe” or “explain” or …
Page 72, lines 141, 160, 161 and 162, change “comprehension” by “Knowledge”
Page 73, lines 182 and 207, change “comprehension” by “Knowledge”
Page 74, line 233, change “understand” by “explain” and “comprehension” by “Knowledge”
Page 75, line 273, change “to be aware” by “identify” or “describe” or “list”, or “rank”; and “comprehension” by “Knowledge”
Page 88, line 28, change “Analysis” by “Evaluation”
Page 89, line 79, change “Comprehension” by “Knowledge”

Duplicated LO in page 152, lines 333 and 334 have the same LO, eliminate one of them

In page 65, line 151, the Learning Outcome “Implement such algorithms as” is incomplete, specialists should complete it, with the algorithms that are expected to be implemented

jose.contreras
Statistics about hours, topics and learning outcomes, by KA
field_vote: 
0
Your rating: None

for curricular design, it would be helpful to know the relative weights of each Knowledge area in terms of hours, topics, and learning outcomes. Here are some of the numbers (I typed them in well formatted columns but the saved version don't show them well) :

QUANTITY OF HOURS PER KA. In the next list, note that 63,4% of the 305 hours of CT1+CT2, are assigned to 6 Knowledge Areas. Here are them shown sorted by (decreased) quantity of hours.

Knowledge Area Qty of hours %
Software Development Fundamentals: 42 13,8%
Discrete Structures: 41 13,2%
Algorithms and Complexity: 28 9,2%
Programming Languages: 28 9,2%
Software Engineering: 27 8,9%
Systems Fundamentals: 27 8,9% sum=63,4%
Arquitecture and Organization 16 5,2%
Social and Professional Practice 16 5,2%
Operating Systems 15 4,9%
Parallel and Distributed Computing 15 4,9%
Information Management 10 3,3%
Intelligent Systems 10 3,3%
Networking and Communication 10 3,3%
Human-Computer Interaction 8 2,6%
Information Assurance and Security 8 2,6%
Graphics and Visualization 3 1,0%
Computational Science 1 0,3%
Platform-Based Development 0 0,0%

QUANTITY OF TOPICS PER KA. In the next list, note that 51% of the 536 topics of CT1 + CT2, belong to 6 Knowledge Areas. Here are them shown sorted by (decreased) quantity of topics.

Knowledge Area Qty of Topics %
Discrete Structures 61 11,4%
Software Engineering 48 9,0%
Programming Languages 44 8,2%
Social and Professional Practice 42 7,8%
Algorithms and Complexity 39 7,3%
Arquitecture and Organization 39 7,3% sum=51%
Systems Fundamentals 38 7,1%
Intelligent Systems 33 6,2%
Operating Systems 31 5,8%
Software Development Fundamentals 31 5,8%
Networking and Communication 30 5,6%
Parallel and Distributed Computing 29 5,4%
Information Assurance and Security 24 4,5%
Human-Computer Interaction 18 3,4%
Information Management 18 3,4%
Graphics and Visualization 10 1,9%
Computational Science 1 0,2%
Platform-Based Development 0 0,0%

QUANTITY OF LO PER KA. In the next list, note that 52,2% of the 523 Learning Outcomes of CT1+CT2, are defined in 6 Knowledge Areas. Here are them shown sorted by (decreased) quantity of Learning Outcomes.

Knowledge Area Qty of LO %
Software Engineering 61 11,7%
Social and Professional Practice 54 10,3%
Systems Fundamentals 43 8,2%
Information Assurance and Security 40 7,6%
Algorithms and Complexity 38 7,3%
Architecture and Organization 37 7,1% sum=52,2%
Operating Systems 36 6,9%
Parallel and Distributed Computing 35 6,7%
Software Development Fundamentals 35 6,7%
Discrete Structures 32 6,1%
Information Management 26 5,0%
Networking and Communication 22 4,2%
Programming Languages 19 3,6%
Intelligent Systems 18 3,4%
Graphics and Visualization 12 2,3%
Human-Computer Interaction 9 1,7%
Computational Science 6 1,1%
Platform-Based Development 0 0,0%

cstone
Familiarity with common themes and principles
field_vote: 
0
Your rating: None

Chapter 3, Page 19, lines 21-26

I agree wholeheartedly that we should expect students to understand the big ideas and recurring themes in computer science. It seems a little odd, though, that the report is so vague about what these ideas and themes actually are.

(Also: since PD/Parallelism Fundamentals makes a direct connection between "controlling access to shared resources" and concurrency, the supplied list of "general principles" is not very broad.)

blahedo
Mapping KUs to courses
field_vote: 
0
Your rating: None

My department has just been doing a curriculum revision and as part of the process, I mapped out where every KU in the body of knowledge fell in our revised courses. Even though the 2013 body of knowledge is still in draft form, it was useful as a sanity check and to help us detect any major holes; as a smaller school with a small CS faculty we had certain constraints on how many courses we could offer and require, so we had to be careful in assembling our required courses.

And I thought it might be useful for someone else to see. It's a little bit funny in that it's not a mapping of an extant curriculum we already had in place, but it's definitely more concrete than a "someone somewhere might possibly try this" suggestion. And I have (or rather, will shortly have) sample syllabi for all the core courses, because we need to submit those internally in order to process the revision through our catalogue.

If anyone would be interested in seeing the mappings, the syllabi, or any other part of it, let me know, I'm happy to share. :)

jose.contreras
I would like to see the mappings...
field_vote: 
0
Your rating: None

Hi!, I have also been preparing some courses taking CS2013 BOK as a guide... I don't have too much advance, and I would like to what you did...
My e-mail jose.contreras@usm.cl
Thanks!
J

djg
comments related to empirical evaluation
field_vote: 
0
Your rating: None

[The following is posted on behalf of participants of the EVALUATE 2012 workshop. See a longer post under the SF discussion. The purpose of also posting here is to make sure the parts relevant to Characteristics of Graduates is not forgotten. --Dan]

This feedback is also viewable as a (better-formatted) pdf, downloadable here:

http://evaluate.inf.usi.ch/sites/default/files/CS2013SFEvaluationReplace...

The following feedback is the result of the EVALUATE 2012 workshop. The workshop was the third in a series of workshops aimed at improving experimental evaluation in computer science (http://evaluate.inf.usi.ch). The meeting was held in Beijing on June 15, 2012 with the theme of Improving Experimental Evaluation through Education. One of the outcomes was a set of proposed changes to the strawman draft of CS2013. We believe that our modest proposal will address our concerns by covering basic principles and practices of evaluation.

The changes we propose include:
• Re-working of the Core-Tier 1 knowledge unit SF/Performance. and renaming it SF/Evaluation Principles.
• Development of a new Core-Tier 2 knowledge unit SF/Evaluation Processes.
• Re-inclusion of experimental evaluation in the description of ‘Characteristics of Graduates’.

CS2013 omits some characteristics of graduates with respect to evaluation that were in 2008 and previous documents (e.g., under the heading of Practical capabilities and skills relating to computer science in Section 4.2 of CS2008). This should be remedied and updated to reflect current needs.

We propose to add the following to the list of characteristics that appear in Chapter 3, ‘Characteristics of Graduates’. The text should be added to page 20, before line 38.
Evaluation

A fundamental skill in computer science is knowing how to design experiments for evaluating computer systems. Therefore graduates need to have a basic understanding of how to design
such experiments, conduct the experiments to collect data, and analyze and interpret the data.

adanyluk
Evaluation
field_vote: 
0
Your rating: None

Thank you for identifying "evaluation" as a theme missing from the Characteristics of Graduates. While we have not included your suggested text verbatim, we have modified the paragraph on "Problem Solving Skills" to include empirical evaluation. You will be able to see this when the next draft is posted.

The "Systems Fundamentals" group is also working to modify/clarify points related to evaluation in the SF knowledge area.

dcdl
First of All: Thank You
field_vote: 
0
Your rating: None

Great job with this document and thank you to the steering committee and all contributors. I believe that the CS community with the ACM and IEEE-CS are at the forefront of worldwide curriculum development and these community efforts are what make that possible.

dcdl
Matching of Topics and Learning Outcomes for Core-Tier-1 and 2
field_vote: 
0
Your rating: None

I believe that the development of compliant CS programs and their associated program evaluation tools may be greatly facilitated if the Learning Outcomes were separated between Core-Tier-1 and Core-Tier-2.

For example in AL/Basic Analysis we could have:

[Core-Tier-1]
Topic: Big O notation, informal definition and use.
Learning Outcomes: Determine, informally, the running time complexity of simple well-known algorithms. [Application]

[Core-Tier-2]
Topic: Big O formal notation.
Learning Outcomes: Calculate, using the big O notation formal definition and properties, asymptotic upper bounds on the running time for simple well-known algorithms.

dcdl
Unique Labeling or Numbering of all Topics and Learning Outcomes
field_vote: 
0
Your rating: None

I believe that it would be helpful for referencing the Topics and Learning Outcomes having a unique system of labeling. In such a system we would label or number, for example, the first topic in 'AR/Digital logic and digital systems' - 'Overview and history of computer architecture', using AR.DLS.T01 or AR.01.T01 (or AR-DSL-T01 or AR-01-T01); With such a labeling then, to refer to a learning outcome (in this document, CS program descriptions, or other external documents) we could for example use AR.DLS.O01 and to refer to a topic we cold use AR.DLS.T01 or AR.01.T01. In order to enable this type of referencing all sub-classifications within KAs and all topics and learning outcomes must be uniquely labeled or numbered.

dcdl
Improved Correspondence between Learning Outcomes and Topics
field_vote: 
0
Your rating: None

I believe that for many KAs we may be able to describe learning outcomes in a way that improves their correspondence with their corresponding topics. Maybe we could even list (and number) the topics and immediately after list the corresponding learning outcomes expected for that topic; naturally some learning outcomes may span across several topics, but that can be fixed with cross-referencing using labels. This matching is especially important for the topics in Core-Tier1 and Core-Tier2 since these two define what the community believes is the Core of a CS curriculum.

dcdl
Consistent Labeling for Levels of Understanding
field_vote: 
0
Your rating: None

In some KAs the levels of understanding are labeled using [Knowledge] or [Application] or [Evaluation] but in others they are labeled writing the words in a different form or using parenthesis rather than square brackets. In addition, some KA topics do not have their corresponding levels of understanding labels. The labeling of levels of understanding ([Knowledge] or [Application] or [Evaluation]) should be made consistent across the document.

dcdl
On the Importance of the Learning Outcomes in Core-Tier1 and 2
field_vote: 
0
Your rating: None

I would like to stress the importance of agreeing on an adequate and MINIMAL set of learning outcomes that is realistic with the Core hours assigned to the topics within Core-Tier1 and Core-Tier2. This document will become the standard guide that defines which is the minimum set of learning outcomes that are REQUIRED for a CS graduate. Both, assessment of graduates and of CS programs will be based on the learning outcomes in Core-Tier1 and Core-Tier2 described in this document. I believe that it is imperative then that the learning outcomes listed in Core-Tier1 and Core-Tier2 must be clear, concise, and achievable within the allocated number of hours.

Ken Calvert
On organization
field_vote: 
0
Your rating: None

This is probably a comment for the next decade's committee, but 18 KAs, many of which overlap significantly, is too many - they just make it difficult to find topics. I think we would be better off with either a flat listing of (unique) topics, or a much coarser grouping (maybe 5-7 areas), with no overlap. Academic disciplines need to be modular - we want interfaces that allow abstraction of what's going on "over in that other area". I don't understand the motivation for the current grouping, beyond the fact that many correspond to the way we (traditionally) identify peoples' areas of expertise.

I also tend to agree with those who comment that the "core" is too broad and therefore not deep enough. I believe that a tighter focus, with a few concepts learned well, serves students better than "exposure" to a vast array of concepts. Here's a thought exercise: consider an "exit exam" that tests all 523 learning outcomes of the core tiers 1 and 2. What should be considered a passing score on such an exam? That is, what mark would a student need in order to be considered a competent computer science graduate, regardless of the student's intended career direction?

Ken Calvert
On organization
field_vote: 
0
Your rating: None

I tried to edit the above post, but there's a bug in the drupal code ("Submit" takes you back to "edit").
I wanted to add that I think the "Systems Fundamentals" and "Software Development Fundamentals" KAs are a step in the direction I'd like to see things go.

sahami
Additional comments (received via email)
field_vote: 
0
Your rating: None

Chapter 2

One of the novel aspects of CS2013 for me is the outward facing nature of the proposed curriculum. Is this properly reflected in the Principles? I imagine that Principle 1 covers it, but I can read that without gaining the full significance. Perhaps make the point more explicitly.

Something about excitement, passion, beauty of the discipline?

Chapter 3

I expected computational thinking to appear, even to feature strongly but perhaps I missed it. Of course this is related to the above comment on Chapter 2.

Is a desirable outcome that curriculum should address the principles underpinning the development of safe and secure systems?

I might like to see mobility, security, etc in the headlines in this chapter.

KNOWLEDGE AREAS

There are places where the learning outcomes are qualified by [knowledge], [Evaluation], etc and in the HC section round brackets ( and ) are used rather than [ and ]. Consistency?

sahami
Comments from CRA Snowbird 2012 meeting
field_vote: 
0
Your rating: None

[Comment below is from the panel session on CS2013 at the CRA Snowbird 2012 meeting.]

For the Professional Practice section consider disciplinary study abroad programs as a way to incorporate international experience into the curriculum.

rleblanc
Project Experience
field_vote: 
0
Your rating: None

Posted for Vaclav Rajlich

Suggested modification:

43 – 50 Project experience
There is a universal expectation by both employers and the graduate schools that the computer science graduates should be able to participate in team software projects. To ensure that, all graduates of computer science programs should have been involved in at least one software development or evolution project. Such projects should follow a well-documented and state-of-the-art software process that scales up to the typical industrial or academic research projects, and produces a currently expected software quality. Students should have opportunities to develop their interpersonal communication skills as part of their project experience.

Log in or register to post comments