0740-7459/13/$31.00 © 2013 IEEE
Published by the IEEE Computer Society
Is the New Software Engineering Curriculum Agile?
ALTHOUGH THE AGILE MANIFESTO
was considered controversial when released in 2001, agile is an accepted practice today, taking its place among disciplined and plan-and-document processes such as spiral and the Rational Unified Process. A recent survey of 66 large software projects in industry found that the majority used agile. 1
The latest editions of two popular software engineering textbooks now introduce agile early, with one author summarizing the conventional wisdom that the decision of whether to use agile depends on the circumstances, as Figure 1
shows. 2 , 3
Figure 1.. Sommerville's 10 questions about whether to use agile. A “no” answer suggests agile; a “yes” suggests plan and document. For student projects, at least 7 of the 10 questions clearly point to agile. 3
As the last standardization effort was done in 2004, the software engineering curriculum is currently being revised. Haven't we reached the point where agile development should be part of all software engineering curricula? And if so, shouldn't new curriculum standards ensure that it is?
Confusingly, there are two such efforts underway today. The first is for computer science departments and includes courses on software engineering. 4
The second, which isn't as far along, is for software engineering departments. 5
This article is about the former, but we'll comment on the latter as well.
Student Projects Match Agile
For student projects in a software engineering course—assuming the project doesn't consist of building a safety-critical app and that students use high-quality open source tools—virtually all the answers to the questions in Figure 1
point to using agile in the classroom. Indeed, our experience confirms agile's benefits. 6
We developed a new software engineering course at the University of California, Berkeley, in which students work with customers from local nonprofit organizations to build a software-as-a-service app using the tools that come with Ruby on Rails. In particular, students perform four agile iterations in a single semester, which gives them enough experience both to learn and to appreciate the benefits of the approach. The course's success inspired us to write a new software engineering textbook 7
and to create a massive open online course ( www.saas-class.org). Others have reported similar results, 8 , 9
reporting that agile particularly benefits women because it addresses factors that limit their participation in computer science. 10 , 11
Agile's synergy with student projects is noteworthy because the 2013 computer science curriculum standard, in which ACM and the IEEE Computer Society have joined forces, starts with a call for students to learn software engineering by working in teams on projects: 4
In general, students learn best at the application level much of the material defined in the [software engineering knowledge area] by participating in a project. Such projects should require students to work on a team to develop a software system through as much of its lifecycle as is possible. Much of software engineering is devoted to effective communication among team members and stakeholders. Utilizing project teams, projects can be sufficiently challenging to require the use of effective software engineering techniques and that students develop and practice their communication skills. While organizing and running effective projects within the academic framework can be challenging, the best way to learn to apply software engineering theory and knowledge is in the practical environment of a project.
Although the standard is agnostic on whether to use plan-and-document or agile processes on these student projects, in practice, it's written from a plan-and-document-centric viewpoint—hence our keen interest in the following question: If faculty follow the conventional wisdom to the answers to the questions in Figure 1
and use agile in classroom projects, can their courses fulfill the new curriculum standard's requirements?
Digging Deeper into the Standard
To find the answer, we delved deep into the standard. Table 1
shows its 10 sections, which cover classic software engineering topics. Each section starts with a bulleted list of topics, followed by a list of learning outcomes that make the topics clearer. The standard divides these 116 learning outcomes into three sections:
• 13 are Core Tier 1—courses following the standard must deliver on 100 percent of these learning outcomes.
• 50 are Core Tier 2—courses following the standard must deliver on at least 80 percent of these outcomes, although ideally achieve 90 to 100 percent.
• 53 are electives—courses covering only core topics will not have sufficient breadth. These electives are intended to be a useful guide for additional material, but none are required.
Table 1.. The ten sections of the latest draft of the new standard.*
We can further classify the learning outcomes according to depth of coverage:
• Familiarity—the student understands what a concept is or what it means. Familiarity answers the question, “What do you know about this?” (53 of the 116 outcomes have this goal.)
• Usage—the student is able to use or apply a concept in a concrete way. Usage answers the question, “What do you know how to do?” (58 of the 116 outcomes have this goal.)
• Assessment—the student is able to consider a concept from multiple viewpoints and/or justify the selection of a particular approach to solve a problem. Assessment answers the question, “Why would you do that?” (5 of the 116 outcomes have this goal.)
shows examples of the depth of coverage for all three tiers from one section of the standard. Speaking as instructors and authors, one upside of the standard is that it led us to expand the material in the course and our book to be more balanced in presenting plan-and-documents along with agile development.
Figure 2.. An example of three types of learning outcomes for requirements engineering (section 4 in Table 1 ). Note that none of the outcomes use agile terms or concepts directly, but with creativity, you can map some of them onto the traditional plan-and-document terms and concepts in these outcomes.
The Committee Forgot Agile
At first blush, the answer to whether agile projects fulfill the standard's outcomes appears to be no. Virtually all the terms come from plan-and–document processes. Here are examples:
• Compare several process improvement models such as CMM, CMMI, CQI, Plan-Do-Check-Act, or ISO9000. [Familiarity]
• Conduct a cost/benefit analysis for a risk mitigation approach. [Usage]
• Create appropriate models for the structure and behavior of software products from their requirements specifications. [Usage]
None of the 116 outcomes use explicit agile terms. Of the 50,000+ words in the standard, the word “agile” only appears twice, and there are only three uses of agile terms in the topics. It's easy—in fact, as the standard is written, it's even natural—to fulfill the 2013 standard with a software engineering course that doesn't mention agile or any of the concepts associated with it: user stories, behavior–driven design, test-driven development, scrum team management, and so on. While plausibly excusable for the prior 2004 standard, it's indefensible for 2013.
If the new standard doesn't include agile, then faculty members face a hard decision:
• follow the outcomes, but ignore the standard's missive and don't offer student projects;
• follow the outcomes and offer a student project as the standard suggests, but ignore the implications of Figure 1 to use agile; or
• ignore the standard's outcomes and offer a student project as the standard recommends, using an agile process as the answers to the questions in Figure 1 suggest.
As the standard document isn't in its final draft, there's still opportunity for change. Given that agile is obviously an accepted practice today and widely used, we strongly recommend a more even balance between plan-and–document and agile processes in the outcomes, particularly for the electives.
As the curriculum committee for software engineering departments formed more recently, we certainly hope that it will learn from the omissions of the other committee and embrace agile as a valid part of the curriculum from the start.
If the computer science standards committee is unyielding, creative individuals can, after studying outcomes in more depth, use agile for projects and meet the minimum outcomes. The standard doesn't require an instructor to cover 100 percent of Core Tier 2 or any of the electives, which makes it easier for projects to follow agile and still meet the standard. We combed through all 13 Core Tier 1 outcomes and 54 Core Tier 2 outcomes, and Table 1
shows the percentage that can be covered if you follow this strategy: 100 percent of Core Tier 1, 94 percent of Core Tier 2, and even 68 percent of the electives. Our instructor's manual on the Web details how we revised the course and the textbook to meet the standard by including sections that contrast agile and plan-and-document methodologies for each of the 10 sections in Table 1
Thus, the answer to the question in the title of this article can be affirmative even if the computer science standards committee is absent-minded. Instructors can follow the initial call of the standard for projects by student teams while using an agile process, which is the most natural match. As long as you review both plan-and-document and agile processes in lecture, students can become familiar with both sets of terms and concepts. The more demanding outcomes can be met by the project as well, provided you look to the deeper meaning behind the plan-and-document terms to see where agile can fit.
is a professor at the University of California, Berkeley. Contact him at firstname.lastname@example.org.
is professor at the University of California, Berkeley. Contact him at email@example.com