The first historical circumstance pertaining to the CS major at GVSU which I’ll present is reflected in my department’s name: “School of Computing and Information Systems“. At GVSU, our CS major shares departmental resources including introductory courses with our Information Systems (IS) major. To be specific, until 2012 students pursuing either of these two majors were required to take the same ‘technical core’ courses during their first year: “CIS 162: Computer Science I”, “CIS 163: Computer Science II”, “MTH 225: Discrete Structures: Computer Science”, “STA 215: Introductory Applied Statistics” (or a more advanced Statistics course), and either “WRT 150: Strategies in Writing” or “COM 201: Speech”. And while our department’s professors naturally meet all together to discuss and decide the curriculum for each of our majors, it was difficult to change critical courses such as CIS 163 for the purposes of the CS major because IS had different aims. Now in 2012, the IS major diverged a little more from the CS major, switching from CIS 163 and MTH 225 to alternatives; but the other ‘technical core’ courses remain shared, again because our department must share our resources, plus we want to facilitate students changing from one of our majors to the other, which happens a lot — if no courses were shared, then changing majors would onerously make students lose a semester or two of time. Then, since the IS major does not involve prerequisites of prior exposure to computer programming or any advanced mathematical qualifications beyond what’s necessary for admission to college, our primary shared course “CIS 162: Computer Science I” is very introductory, really starting from nothing. Then after that rudimentary course in the first semester, it is difficult for our sequel CS course “CIS 163: Computer Science II” to progress very far in computer science; for example, it has only one week to cover linked lists, and it does not cover binary trees at all.

Another historical circumstance pertaining to the CS major at GVSU concerns the C programming language. As you may know, although C is now old, it remains important: consider that the TIOBE Programming Community index gives C the highest rating of approximately 17.5%, it gives Java the second-highest rating of approximately 15%, next Objective-C approximately 9%, and then C++ approximately 6% — and the latter two languages obviously use C programming at their core. Consistent with such prominence of C, our CS major at GVSU includes significant courses which use C, e.g. “CIS 452: Operating Systems Concepts”. But… our coverage of C has actually varied somewhat. As of 2002, our CS major included the required course “CS 361: C and Unix”. The next year, the CS major underwent changes including the following:

“We are dropping CS 361 as a requirement and will eventually drop it from the catalog as well. [...] Some content from this course will be moved to CS 163 which is expanding to a four hour course and CS 343 which already covers the C and C++ programming languages. This course will now be accepted as an elective. [...] The CS curriculum is consistent with the national curriculum as reported in the ACM/IEEE-CS Joint Task Force on Computing Curricula 2000.”

That referenced course “C[I]S 343″ is “Structure of Programming Languages”. As usual at any university, such a course surveys the range of programming languages, so it includes discussion of C and maybe C++; but for it to really teach all of C is difficult. So now, professors who want to use C in courses such as “CIS 452: Operating Systems Concepts” observe that students who learned C by happening to have chosen the elective CIS 361 smoothly handle the C programming, while other students who have not taken CIS 361 struggle with it.

Now it’s fair to counter, “But… the ACM/IEEE CS Curriculum Guidelines don’t mandate teaching the specific language C.” That is true; however, the Guidelines do specify including material such as “references and aliasing” , “manual memory management”, and “how fundamental high-level programming constructs are implemented at the machine-language level”; and clearly the C programming language is currently the best environment for thoroughly teaching such material. Anyway, aside from C, some other material specified by the Guidelines which we need to cover better is as follows:

clear coverage of algorithmic strategies such as brute-force vs. greedy

full coverage of the Knowledge Unit “AL/Basic Automata, Computability, and Complexity” [3 Core-Tier1 hours plus 3 Core-Tier2 hours], which includes topics such as finite-state machines, regular expressions, and introduction to the P and NP classes and the P vs. NP problem

full coverage of the Knowledge Unit “SF/Evaluation” [3 Core-Tier1 hours]

Now of course, sometimes some of our instructors have optionally covered some of this material. (And again, some of this material such as automata was included in our required courses until the 2002/03 change.) However, we don’t have this material really ‘nailed down’ clearly in our curriculum right now.

So we’ve been discussing how we might address these deficiencies of our curriculum, including discussing some elements actually for several years before the publication of the 2013 ACM/IEEE CS Curriculum Guidelines. But… as I indicated above, sometimes we’ve been held back because of competing purposes for our courses such as “CIS 163: Computer Science II”. Or last semester, we were ‘holding our breath’ while ABET was evaluating us for reaccreditation; and that may actually occupy some more time for us since we need to address some concerns they raised. Is there any hope for us to clean up our ‘mess’?!?

Well now, looking more at ACM/IEEE Computer Science Curriculum Guidelines, consider the following (to see the image larger, click it or view page 37 in the original document):
In that redistribution of Core hours among Knowledge Areas, note particularly that the Knowledge Area “Architecture and Organization” was previously assigned 36 Core hours but now is assigned only 16 Core-Tier2 hours. At GVSU, we taught all the previously-specified Architecture and Organization in two required courses, “CIS 251: Computer Organization” and “CIS 451: Computer Architecture”. Now, however, considering the lessening of hours for this Knowledge Area, we should be able to cover the necessary material in just one course.

And if we do remove one required course from our CS major, what can we do with that available space? Why, change CIS 361 on C back to a required course again! Though of course, we’d also take this opportunity to satisfy more ACM/IEEE CS Curriculum Guidelines, e.g. covering version control and changing topics in further courses to address the deficiencies itemized above. (These changes to our curriculum would to some extent be performing an ‘undo’ of the changes done in 2002/03.)

But… there are complications. For one thing, students should take this ‘new’ required course on C etc. in their second year to maximize the opportunity for later courses to use C; but… inserting a course at such a random point in the curriculum would necessitate displacing various other courses, and possibly lengthening our CS major’s prerequisite chains of courses. And… if the prerequisite chains of courses are too long, then students might find it difficult to graduate from college in four years if they need to do anything unusual, e.g. studying abroad which entails missing a semester or two of our courses, or if they’re transfer students from community colleges who have completed General Education and need to just take CS major courses.

Another ‘but…’ concerns Computer Organization and Architecture. It’s actually difficult to cram all the necessary material into just one semester; it would help if some topics such as binary number representation were taught elsewhere such as in “MTH 225: Discrete Structures: Computer Science”. But… that course is under the purview of the Mathematics department, so we can’t just willy-nilly dictate what happens in it.

And another ‘but…’ concerns “CIS 163: Computer Science II”. It’s a critical course: it needs to transition students from the very introductory course “CIS 162: Computer Science I” to, well, all of Computer Science; it’s the principal prerequisite for most of our CS courses. And its current setup includes some Linux material which should be covered in CIS 361. Then making CIS 361 required again means that CIS 163 might have some room to cover different material, e.g. basic binary trees. But… should this be done? Our students currently find CIS 163 very challenging; instead of adding more material to CIS 163, should we just lengthen coverage of the material that’s already in it, so it’ll be easier?

Stay tuned to find out what happens to our intrepid department facing the prospect of modernizing our CS major. Will we make changes as described above? Or will we encounter more “but…”s which hinder this process?

How has modernization of your CS major proceeded at your institution? Do you want to compare your situation to the situation at GVSU? Or how about this: Do you want to get together with me and write up a cross-institution experience report on curricular reform being done to conform to the new ACM/IEEE CS Curriculum Guidelines? I’m game if you are….

One Response to We Aspire to Comply with the ACM/IEEE CS Curriculum Guidelines — But…, But…, But….

We at RWU are also undergoing a major review of our program against the newest guidelines. But at this point we are looking at the guidelines as a basis for potential curriculum changes rather than as a set of “must-dos”