Questioning the value of CS2013

I recently had cause to re-read the ACM/IEEE CS2013 curriculum recommendations. This document is created by a large committee of content experts to provide guidance to Computer Science undergraduate programs. On one hand, it's a useful articulation of the body of knowledge that constitutes "Computer Science". On the other hand, well, let's take a closer look.

The CS2013 document breaks down Computer Science into knowledge areas such as Discrete Structures, Human-Computer Interaction, Operating Systems, and Software Engineering. Within the Software Engineering (SE) topic is a section called SE/Software Project Management. The section contains "2 core Tier2 hours", which means there are two recommended minimum contact hours on the topic, and they should be in a non-introductory course. For those who don't know the higher education jargon, "contact hours" means "students and faculty together in a formal meeting" such as a lecture. According to US financial aid legislation, and therefore according to practically every domestic institution of higher education, a student is expected to engage in two additional effort hours for each contact hour. For example, a student is expected to read, study, or work on homework for two hours for each one-hour lecture.

The core topics contained within SE/Software Project Management are as follows:

• Team participation
• Team processes including responsibilities for tasks, meeting structure, and work schedule
• Roles and responsibilities in a software team
• Team conflict resolution
• Risks associated with virtual teams (communication, perception, structure)
• Effort Estimation (at the personal level)
• Risk (cross reference IAS/Secure Software Engineering)
• The role of risk in the lifecycle
• Risk categories including security, safety, market, financial, technology, people, quality, structure and process

That's a lot of topics to cover in two hours of lecture and four hours of studying, but I could see it being all combined into a breakneck chapter of a Software Engineering textbook. Note that there are additional elective topics within SE/Software Project Management, but we won't consider those for this discussion.

Part of the ostensible value of CS2013 is that it doesn't just provide a topic list for each section of a knowledge area: it also provides learning outcomes. These are classified in a system inspired by Bloom's Taxonomy of the Cognitive Domain, so each outcome can be at the level of Familiarity, Usage, or Assessment. These are defined on page 34 of CS2013, and we can summarize them as basic awareness, ability to deploy knowledge concretely, and being able to consider from multiple viewpoints—as one would infer from the nomenclature. These, then, are the learning outcomes for SE/Software Project Management, as listed on page 177 of CS2013:

1. Discuss common behaviors that contribute to the effective functioning of a team. [Familiarity] 
2. Create and follow an agenda for a team meeting. [Usage]
3. Identify and justify necessary roles in a software development team. [Usage]
4. Understand the sources, hazards, and potential benefits of team conflict. [Usage]
5. Apply a conflict resolution strategy in a team setting. [Usage]
6. Use an ad hoc method to estimate software development effort (e.g., time) and compare to actual effort required. [Usage]
7. List several examples of software risks. [Familiarity]
8. Describe the impact of risk in a software development lifecycle. [Familiarity]
9. Describe different categories of risk in software systems. [Familiarity]

It's pretty clear to me that it's impossible to meet those nine objectives in two contact hours and four out-of-class work hours. Even if we assume that each student is perfectly capable of independent learning and studying, the time required to make any meaningful knowledge about these items is certainly greater than the recommended hours. I recognize that I am making assertions here and not arguments. In an earlier draft of this post, I tried a more rigorous argument, but I realized that a true skeptic could always counterclaim that they could meet these goals within the timeline. The real difference would not be the time required but our mutually exclusive definition of what it means to meet a learning objective.

It seems to me, then, that there are only two ways this could be approved by a committee. The first is that the committee has no functional understanding of contemporary learning theory. If that were the case, then why should anyone take their recommendations for curricula seriously? The second option is negligence, that the committee as a whole knew better, but they did not verify whether their recommendations and the learning objectives actually align. If that's the case, then why should anyone take their recommendations seriously?