Software Engineering 2014 Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering a volume of the Computing Curricula Series

Designing an Undergraduate Degree Program

Developing a degree program is of course a classic example of a design task. There are many constraints and a need to make trade-offs among different factors; there are no right or wrong solutions, only ones that are better or worse with respect to specific criteria. What is more, much of this is specific to the context of a particular institution, its ethos, and the type of students that it recruits. There are some obvious parallels with software design in the way that a curriculum has both static aspects (the mapping of topics to modules) and dynamic ones (how these are to be delivered).

This chapter begins by identifying some of the key factors and how they might influence design choices. There is also a brief review of some ideas about how a curriculum might be organized. At the end of each issue reviewed in this chapter, the relevant curriculum guidelines are referenced using a table. (Although many guidelines address more than one of these themes, each guideline is associated here with the theme judged most relevant.)

Factors to Consider When Designing a Degree Program

The major stakeholders in the degree program will include at least the following:

• 
  Students. A curriculum needs to reflect the students’ needs in many ways. They are likely to expect a program that will prepare them for employment and/or research in terms of both their knowledge and skills, as discussed in Section 3.1. Students also enter a degree program with an educational background that will influence how the curriculum is organized and presented and that is likely to be specific to the context of a particular country. A degree program also needs to provide an intellectual challenge together with a sense of excitement about the discipline.
  
• 
  Teaching staff. Not only do instructors need to motivate, interest, and encourage students, they also have to provide expert knowledge where appropriate. The need for employing people who are able to address these needs was identified in Chapters 2 and 5.
  
• 
  Institution. Each university or college has its own ethos and structures. At one level, this might influence the type of applications that are used to illustrate teaching; at another it will determine the size of a course or module as well as the ways that it might be assessed. It may also be necessary to offer a software engineering degree program as part of a “package” of programs, sharing some courses and resources.
  
• 
  Professional bodies. Professional organizations play a major role in setting standards in the accreditation of degree programs as well as in long-term (post-degree) development through the provision of continuing professional development (CPD) opportunities and programs.
  

As emphasized in Chapter 4 and elsewhere, the SEEK identifies knowledge areas and knowledge units in a topic-oriented manner that is not meant to form a blueprint for mapping to courses. Indeed, many topics may need to be covered at more than one level or from more than one perspective. For example, the discussion of professional issues may occur when teaching a range of topics. Similarly, a given course may incorporate a set of knowledge units taken from different knowledge areas.

A key issue is that of the dependency among topics. A fairly fundamental example is that most software engineering topics implicitly require a basic understanding of programming and of some of the ways that software can be organized (architecture). Others, such as the knowledge units making up software design, and many of the ideas about quality, tend to require a significant level of maturity of understanding together with a breadth of knowledge about many topics if they are to be taught at any depth.

Although design models for curricula, like those for software and other artifacts, may not be right or wrong, there are some rather general criteria that might usefully be considered when reviewing a curriculum model:

• 
  Avoid duplication. Although a topic or knowledge unit might well be covered more than once, especially when expanding detail or addressing more advanced aspects in later courses, there is a need to ensure that teaching about particular issues is not duplicated unnecessarily.
  
• 
  Ensure that crosscutting issues get appropriate coverage and that ideas are developed systematically. Although such issues are generally best addressed across multiple courses, to emphasize their wider significance, it is necessary to ensure that the key ideas are gradually expanded and to keep track of their development.
  
• 
  Provide iteration of development experience so that students can reflect, learn, and revise their ideas as appropriate.
  
• 
  Ensure that there is clear justification for including any material not directly related to software engineering. This is likely to arise when a degree program is part of a portfolio of programs. For example, while the SEEK identifies some branches of mathematics, such as statistics, it does not include calculus because this is rarely used in software engineering, and then it is used only when needed for a particular application domain. There may well be good reasons for including a calculus course (such as giving students the option to change their choice of program at the end of the first year), but this should then be seen as part of a general requirement and not presented as part of the software engineering program.