Guidelines for SE Curriculum Design and Delivery

<< Overview of Software Engineering Education Knowledge

Courses and Course Sequences >>

Chapter 5: Guidelines for SE Curriculum Design and Delivery

Chapter 4 of this document presents the SEEK, which includes the knowledge that software

engineering graduates need to be taught. However, how the SEEK topics should be taught may

be as important as what is taught. In this chapter, a series of guidelines are described, which

should be considered by those developing an undergraduate SE curriculum and by those teaching

individual SE courses.

5.1

Guideline Regarding those Developing and Teaching the Curriculum

Curriculum Guideline 1: Curriculum designers and instructors must have sufficient

relevant knowledge and experience and understand the character of software engineering.

Curriculum designers and instructors should have engaged in scholarship in the broad area of

software engineering. This implies:

· Having software engineering knowledge in most areas of SEEK.

Obtaining real-world experience in software engineering.

Becoming recognized publicly as knowledgeable in software engineering either by having a

track record of publication, or being active in an appropriate professional society.

Increasing their exposure to the continually expanding variety of domains of application of

software engineering (such as other branches of engineering, or business applications), while

being careful not to claim to be experts in those domains.

Possessing the motivation and the wherewithal to keep up-to-date with developments in the

discipline

Failure to adhere to this principle will open a program or course to certain risks:

· A program or course might be biased excessively to one kind of software or class of

methods, thus not giving students a broad enough exposure to the field, or an inaccurate

perception of the field. For example, instructors who have experienced only real-time or only

data processing systems are at risk of flavoring their programs excessively towards the type

of systems they know. While it is not bad to have programs that are specialized towards

specific types of software engineering such as these, these specializations should be

explicitly acknowledged in course titles. Also, in a program as a whole, students should

eventually be exposed to a comprehensive selection of systems and approaches.

Faculty who have a primarily theoretical computer science background might not adequately

convey to students the engineering-oriented aspects of software engineering.

Faculty from related branches of engineering might deliver a software engineering program

or course without a full appreciation of the computer science fundamentals that underlie so

much of what software engineers do. They might also not cover software for the wide range

of domains beyond engineering to which software engineering can be applied.

Faculty who have not experienced the development of large systems might not appreciate the

importance of process, quality, evolution, and management (which are knowledge areas of

SEEK).

SE2004 Volume 8/23/2004

Faculty who have made a research career out of pushing the frontiers of software

development might not appreciate that students first need to be taught what they can use in

practice and need to understand both practical and theoretical motivations behind what they

are taught.

5.2

Guidelines for Constructing the Curriculum

Curriculum Guideline 2: Curriculum designers and instructors must think in terms of

outcomes.

Both entire programs and individual courses should include attention to outcomes or learning

objectives. Furthermore, as courses are taught, these outcomes should be regularly kept in mind.

Thinking in terms of outcomes helps ensure that the material included in the curriculum is

relevant and is taught in an appropriate manner and at an appropriate level of depth.

The SE2004 graduate outcomes (see Chapter 2) should be used as a basis for designing and

assessing software engineering curricula in general. These can be further specialized for the

design of individual courses.

In addition, particular institutions may develop more specialized outcomes (e.g. particular

abilities in specialized applications areas, or deeper abilities in certain SEEK knowledge areas).

Curriculum Guideline 3: Curriculum designers must strike an appropriate balance

between coverage of material, and flexibility to allow for innovation.

There is a tendency among those involved in curriculum design to fill up a program or course

with extensive lists of things that "absolutely must" be covered, leaving relatively little time for

flexibility, or deeper (but less broad) coverage.

However, there is also a strong body of opinion that students who are given a foundation in the

`basics' and an awareness of advanced material should be able to fill in many kinds of `gaps' in

their education later on, perhaps in the workforce, and perhaps on an as-needed basis. This

suggests that certain kinds of advanced process-oriented SEEK material, although marked at an

`a' (application) level of coverage, could be covered at a `k' level if absolutely necessary to

allow for various sorts of curriculum innovation. However, material with deeper technical or

mathematical content marked `a' should not be reduced to `k' coverage, since it is tends to be

much harder to learn on the job.

Curriculum Guideline 4: Many SE concepts, principles, and issues should be taught as

recurring themes throughout the curriculum to help students develop a software

engineering mindset.

Material defined in many SEEK units should be taught in a manner that is distributed throughout

many courses in the curriculum. Generally, early courses should introduce the material, with

subsequent courses reinforcing and expanding upon the material. In most cases, there should also

be courses, or parts of courses, that treat the material in depth.

SE2004 Volume 8/23/2004

In addition to ethics and tool use, which will be highlighted specifically in other guidelines, the

following are types of material that should be presented, at least in part, as recurring themes:

· Measurement, quantification, and formal or mathematical approaches

Modeling, representation, and abstraction.

Human factors and usability: Students need to repeatedly see how software engineering is

not just about technology.

The fact that many software engineering principles are in fact core engineering principles:

Students may learn SE principles better if they are shown examples of the same principle in

action elsewhere: e.g. the fact that all engineers use models, measure, solve problems, use

`black boxes', etc.

The importance of scale: Students can practice only on relatively small problems, yet they

need to appreciate that the power of many techniques is most obvious in large systems. They

need to be able to practice tasks as if they were working on very large systems, and to

practice reading and understanding large systems.

The importance of reuse.

Much of the material in the Process, Quality, Evolution, and Management knowledge areas.

Curriculum Guideline 5: Learning certain software engineering topics requires maturity,

so these topics should be taught towards the end of the curriculum, while other material

should be taught earlier to facilitate gaining that maturity.

It is important to structure the material that has to be taught so that students fully appreciate the

underlying principles and the motivation. Thus if taught too early in the curriculum, many topics

from SEEK's Process, Quality, Evolution, and Management knowledge areas are likely to be

poorly understood and poorly appreciated by students. This should be taken into account when

designing the sequence in which material is to be taught and how real-world experiences are

introduced to the students. It is suggested that introductory material on these topics can be taught

in early years, but that the bulk of the material be left to the latter part of the curriculum.

On the other hand, students also need very practical material to be taught early so they can begin

to gain maturity by participating in real-world development experiences (in the work force or in

student projects). Examples of topics whose teaching should start early include programming,

human factors, aspects of requirements and design, as well as verification and validation. This

does not mean to imply that programming has to be taught first, as in a traditional CS1 course,

but that at least a reasonable amount should be taught in a student's first year.

Students should also be exposed to "difficult" software engineering situations relatively early in

their program. Examples of these might be dealing with rapidly changing requirements, having

to understand and change a large existing system, having to work in a large team, etc. The

concept behind such experiences is to raise awareness in students that process, quality, evolution

and management are important things to study, before they start studying them.

SE2004 Volume 8/23/2004

Curriculum Guideline 6: Students must learn some application domain (or domains)

outside of software engineering.

Almost all software engineering activity will involve solving problems for customers in domains

outside software engineering. Therefore, somewhere in their curriculum, students should be able

to study one or more outside domains in reasonable depth.

Studying such material will not only give the student direct domain knowledge they can apply to

software engineering problems, but will also teach them the language and thought processes of

the domain, enabling more in-depth study later on.

By `in reasonable depth' we mean one or more courses that are at more than the introductory

level (at least heavy second year courses and beyond). The choice of domain (or domains) is a

local consideration, and in many cases can be at least partly left up to the student. Domains can

include other branches of engineering or the natural sciences; they can also include social

sciences, business and the humanities. No one domain should be considered `more important' to

software engineering programs than another.

The study of certain domains may necessitate additional supporting courses, such as particular

areas of mathematics and computer science as well as deeper areas of software engineering. The

reader should consult the Systems and Application Specialties area at the end of SEEK (Chapter

4) to see recommendations for such supporting courses.

This guideline does not preclude the possibility of designing courses or programs that deeply

integrate the teaching of domain knowledge with the teaching of software engineering. In fact,

such an approach would be innovative and commendable. For example an institution could have

courses called `Telecommunications Software Engineering', `Aerospace Software Engineering',

`Information Systems, Software Engineering', or `Software Engineering of Sound and Music

Systems'. However, in such cases great care must be taken to ensure that the depth is not

sacrificed in either SE or the domain. The risk is that the instructor, the instructional material, or

the presentation may not have adequate depth in one or the other area.

5.3

Attributes and Attitudes that should Pervade the Curriculum and its

Delivery

Curriculum Guideline 7: Software engineering must be taught in ways that recognize it is

both a computing and an engineering discipline.

Educators should develop an appreciation of those aspects of software engineering that it shares

in common both with other branches of engineering and with other branches of computing,

particularly computer science. Characteristics of engineering and computing are presented in

Chapter 2.

Engineering: Engineering has been evolving for millennia, and a great deal of general

wisdom has been built up, although some parts of it need to be adapted to the software

engineering context. Software engineering students must come to believe that they are real

engineers: They must develop a sense of the engineering ethos, and an understanding of the

SE2004 Volume 8/23/2004

responsibilities of being an engineer. This can be achieved only by appropriate attitudes on

the part of all faculty and administrators.

This principle does not require that software engineers must endorse all aspects of the

engineering profession. There are those, within and outside the profession, who criticize

some aspects of the profession, and their views should be respected, with an eye to

improving the profession. Also, there are some ways that software engineering differs from

other types of engineering (e.g. producing a less tangible product, and having roots in

different branches of science), and these must be taken into account. This principle also does

not require that a particular model of the profession be adopted.

Computing: For software engineers to have the technical competence to develop high-

quality software, they must have a solid and deep background in the fundamentals of

computer science, as outlined in Chapter 4. That knowledge will ensure they understand the

limits of computing, and the technologies available to undertake a software engineering

project.

This principle does not require that a software engineer's knowledge of these areas be as deep

as a computer scientist's. However, the software engineer needs to have sufficient

knowledge and practice to choose among and apply these technologies appropriately. The

software engineer also must have sufficient appreciation for the complexity of these

technologies to recognize when they are beyond their area of expertise and when they

therefore need to consult a specialist (e.g., a database analyst).

Curriculum Guideline 8: Students should be trained in certain personal skills that

transcend the subject matter.

The skills below tend to be required for almost all activities that students will encounter in the

workforce. These skills must be acquired primarily through practice:

· Exercising critical judgment: Making a judgment among competing solutions is a key part

of what it means to be an engineer. Curriculum design and delivery should therefore help

students build the knowledge, analysis skills, and methods they need to make sound

judgments. Of particular importance is a willingness to think critically. Students should also

be taught to judge the reliability of various sources of information.

Evaluating and challenging received wisdom: Students should be trained to not

immediately accept everything they are taught or read. They should also gain an

understanding of the limitations of current SE knowledge, and how SE knowledge seems to

be developing.

Recognizing their own limitations: Students should be taught that professionals consult

other professionals and that there is great strength in teamwork.

Communicating effectively: Students should learn to communicate well in all contexts: in

writing, when giving presentations, when demonstrating (their own or others') software, and

when conducting discussions with others. Students should also build listening, cooperation,

and negotiation skills.

SE2004 Volume 8/23/2004

Behaving ethically and professionally. Students should learn to think about the ethical,

privacy, and security implications of their work. See also guideline 15.

There are some SEEK topics relevant to the above which can be taught in lectures, especially

aspects of communication ability; but students will learn these skills most effectively if they are

constantly emphasized though group projects, carefully marked written work, and student

presentations.

Curriculum Guideline 9: Students should be instilled with the ability and eagerness to

learn.

Since so much of what is learned will change over a student's professional career, and since only

a small fraction of what could be learned will be taught and learned at university, it is of

paramount importance that students develop the habit of continually expanding their knowledge.

Curriculum Guideline 10: Software engineering must be taught as a problem-solving

discipline.

An important goal of most software projects is solving customers' problems, both explicit and

implicit. It is important to recognize this when designing programs and courses: Such

recognition focuses the learner on the rationale for what he or she is learning, deepens the

understanding of the knowledge learned, and helps ensure that the material taught is relevant.

Unfortunately, a mistake commonly made is to focus on purely technical problems, thus leading

to systems that are not useful.

There are a variety of classes of problems, all of which are important. Some, such as analysis,

design, and testing problems, are product-oriented and are aimed directly at solving the

customers' problem. Others, such as process improvement, are meta-problems whose solution

will facilitate the product-oriented, problem-solving process. Still others, such as ethical

problems, transcend the above two categories.

Problem solving is best learned through practice, and taught through examples. Having a teacher

show a solution on the screen can go part of the way, but is never sufficient. Students therefore

must be given a significant number of assignments.

Curriculum Guideline 11: The underlying and enduring principles of software engineering

should be emphasized, rather than details of the latest or specific tools.

The SEEK lists many topics that can be taught using a variety of different computer hardware,

software applications, technologies, and processes (which we will refer to collectively as tools).

In a good curriculum, it is the enduring knowledge in the SEEK topics that must be emphasized,

not the details of the tools. The topics are supposed to remain valid for many years; as much as

possible, the knowledge and experience derived from their learning should still be applicable 10

or 20 years later. Particular tools, on the other hand, will rapidly change. It is a mistake, for

example, to focus excessively on how to use a particular vendor's piece of software, on the

detailed steps of a methodology, or on the syntax of a programming language.

Applying this guideline to languages requires understanding that the line between what is

enduring and what is temporary can be somewhat hard to pinpoint, and can be a moving target. It

is clear, for example, that software engineers should definitely learn in detail several

programming languages, as well as other types of languages (such as specification languages).

SE2004 Volume 8/23/2004

This guideline should be interpreted as saying that when learning such languages, students must

learn much more than just surface syntax, and, having learned the languages, should be able to

learn whatever new languages appear with little difficulty.

Applying this guideline to processes (also known as `methods' or `methodologies') is similar to

applying it to languages. Students ought not to have to memorize long lists of steps, but should

instead learn the underlying wisdom behind the steps such that they can choose whatever

methodologies appear in the future, and can creatively adapt and mix processes.

Applying this guideline to technologies (both hardware and software) means not having to

memorize in detail an API, user interface, or instruction set just for the sake of memorizing it.

Instead, students should develop the skill of looking up details in a reference manual whenever

needed, so that they can concentrate on more important matters.

Curriculum Guideline 12: The curriculum must be taught so that students gain experience

using appropriate and up-to-date tools, even though tool details are not the focus of the

learning.

Performing software engineering efficiently and effectively requires choosing and using the most

appropriate computer hardware, software tools, technologies, and processes (again, collectively

referred to as tools). Students must therefore be habituated to choosing and using tools, so that

they go into the workforce with this habit a habit that is often hard to pick up in the workforce,

where the pressure to deliver results can often cause people to hesitate to learn new tools.

Appropriateness of tools must be carefully considered. A tool that is too complex, too unreliable,

too expensive, too hard to learn given the available time and resources, or provides too little

benefit, is inappropriate, whether in the educational context or in the work context. Many

software engineering tools have failed because they have failed this criterion.

Tools should be selected that support the process of learning principles.

Tools used in curricula must be reasonably up-to-date for several reasons: a) so that students can

take the tools into the workplace as `ambassadors' performing a form of technology transfer; b)

so that students can take advantage of the tool skills they have learned; c) so that students and

employers will not feel the education is out of-date, even if up-to-date principles are being

taught. Having said that, older tools can sometimes be simpler, and therefore more appropriate

for certain needs.

This guideline may seem in conflict with Curriculum Guideline 11, but that conflict is illusory.

The key to avoiding the conflict is recognizing that teaching the use of tools does not mean that

the object of the teaching is the tools themselves. Learning to use tools should be a secondary

activity performed in laboratory or tutorial sessions, or by the student on his or her own. Students

should realize that the tools are only aids, and they should learn not to fear learning new tools.

SE2004 Volume 8/23/2004

Curriculum Guideline 13: Material taught in a software engineering program should,

where possible, be grounded in sound research and mathematical or scientific theory, or

else widely accepted good practice.

There must be evidence that whatever is taught is indeed true and useful. This evidence can take

the form of validated scientific or mathematical theory (such as in many areas of computer

science), or else widely used and generally accepted best practice.

It is important, however, not to be overly dogmatic about the application of theory: It may not

always be appropriate. For example, formalizing a specification or design, so as to be able to

apply mathematical approaches, can be inefficient and reduce agility in many situations. In other

circumstances, however, it may be essential.

In situations where material taught is based on generally accepted practice that has not yet been

scientifically validated, the fact that the material is still open to question should be made clear.

When teaching "good practices", they should not be presented in a context-free manner, but by

using examples of the success of the practices, and of failure caused by not following them. The

same should be true when presenting knowledge derived from research.

This guideline complements Curriculum Guideline 11. Whereas curriculum Guideline 11

stresses focus on fundamental software engineering principles, Curriculum Guideline 13 says

that what is taught should be well founded.

Curriculum Guideline 14: The curriculum should have a significant real-world basis.

Incorporating real-world elements into the curriculum is necessary to enable effective learning of

software engineering skills and concepts A program should be set up to incorporate at least

some of the following:

· Case studies: Exposure to real systems and project case studies, taught to critique these as

well as to reuse the best parts of them.

Project-based classes: Some courses should be set up to mimic typical projects in industry.

These should include group-work, presentations, formal reviews, quality assurance, etc. It

can be beneficial if such a course were to include a real-world customer or customers. Group

projects can be interdisciplinary. Students should also be able to experience the different

roles typical in a software engineering team: project manager, tools engineer, requirements

engineer, etc.

Capstone course(s): Students need a significant project, preferably spanning their entire last

year, in order to practice the knowledge and skills they have learned. Unlike project-based

classes, the capstone project is managed by the students and solves a problem of the student's

choice. Discussion of a capstone course in the curriculum can be found in Section 6.3.2. In

some locales group capstone projects are the norm, whereas in others individual capstone

projects are required.

Practical exercises: Students should be given practical exercises, so that they can develop

skills in current practices and processes.

Student work experience: Where possible, students should have some form of industrial

work experience as a part of their program. This could take the form of one or more

SE2004 Volume 8/23/2004

internships, co-op work terms, or sandwich work terms (the terminology used here is clearly

country-dependent). It is desirable, although not always possible, to make work experience

compulsory. If opportunities for work experience are difficult to provide, then simulation of

work experience must be achieved in courses.

Despite the above, instructors should keep in mind that the level of real-world exposure their

students can achieve as an undergraduate will be limited: students will generally come to

appreciate the extreme complexity and the true consequences of poor work only by bitter

experience as they work on various projects in their careers. Educators can only start the process

of helping students develop a mature understanding of the real world; and educators must realize

that it will be a difficult challenge to enable students to appreciate everything they are taught.

Curriculum Guideline 15: Ethical, legal, and economic concerns, and the notion of what it

means to be a professional, should be raised frequently.

One of the key reasons for the existence of a defined profession is to ensure that its members

follow ethical and professional principles. By taking opportunities to discuss these issues

throughout the curriculum, they will be come deeply entrenched. One aspect of this is exposing

students to standards and guidelines. See Section 2.4 for further discussion of professionalism.

5.4

General Strategies for Software Engineering Pedagogy

Curriculum Guideline 16: In order to ensure that students embrace certain important

ideas, care must be taken to motivate students by using interesting, concrete and

convincing examples.

It may be only through bitter experience that software engineers learn certain concepts and

techniques considered central to the discipline. In some cases, the educational community has

not appreciated the value of such concepts and has therefore not taught them. In other cases

educators have encountered skepticism on the part of students.

In these cases, there is a need to put considerable attention into motivating students to accept the

ideas, by using interesting, concrete, and revealing examples. The examples should be of

sufficient size and complexity so as to demonstrate that using the material being taught has

obvious benefits, and that failure to use the material would lead to undesirable consequences.

The following are examples of areas where motivation is particularly needed:

· Mathematical foundations: Logic and discrete mathematics should be taught in the context of

its application to software engineering or computer science problems. If derivations and

proofs are to be presented, these should preferably be taught following motivation of why the

result is important. Statistics and empirical methods should likewise be taught in an applied,

rather than abstract, manner.

Process and quality: Students must be made aware of the consequences of poor processes and

bad quality. They must also be exposed to good processes and quality, so that they can

experience for themselves the effect of improvements, feel pride in their work, and learn to

appreciate good work.

SE2004 Volume 8/23/2004

Human factors and usability: Students will often not appreciate the need for attention to these

areas unless they actually experience usability difficulties, or watch users having difficulty

using software.

Curriculum Guideline 17: Software engineering education in the 21st century needs to

move beyond the lecture format: It is therefore important to encourage consideration of a

variety of teaching and learning approaches.

The most common approach to teaching software engineering material is the use of lectures,

supplemented by laboratory sessions, tutorials, etc. However, alternative approaches can help

students learn more effectively. Some of the approaches that might be considered to supplement

or even largely replace the lecture format in certain cases, include:

· Problem-based learning: This has been found to be particularly useful in other professional

disciplines, and is now used to teach engineering in some institutions. See Curriculum

Guideline 10 for a discussion of the problem-solving nature of the discipline.

Just-in-time learning: Teaching fundamental material immediately before teaching the

application of that material. For example, teaching aspects of mathematics the day before

they are applied in a software engineering context. There is evidence that this helps students

retain the fundamental material, although it can be difficult to accomplish since faculty must

co-ordinate across courses.

Learning by failure: Students are given a task that they will have difficulty with. They are

then taught methods that would enable them in future to do the task more easily.

Self-study materials that students work through on their own schedule. This includes on-line

and computer-based learning.

Curriculum Guideline 18: Important efficiencies and synergies can be achieved by

designing curricula so that several types of knowledge are learned at the same time.

Many people browsing through the SEEK have commented that there is a very large amount of

material to be taught, or contrarily, that many topics are assigned a rather small number of hours.

However, if careful attention is paid to the curriculum, many topics can be taught concurrently;

in fact two topics listed as requiring x and y hours respectively may be taught together in less

than x+y hours.

The following are some of the many situations where such synergistic teaching and learning may

be applied:

Modeling, languages, and notations: Considerable depth in languages such as UML can be

achieved by merely using the notation when teaching other concepts. The same applies to

formal methods and programming. Clearly there will need to be some time set aside to teach

the basics of a language or modeling technique per se, but both broad and deep knowledge

can be learned as students study a wide range of other topics.

Process, quality, and management: Students can be instructed to follow certain processes as

they are working on exercises or projects whose explicit objective is to learn other concepts.

In these circumstances, it would be desirable for students to have had some introduction to

process, so that they know why they are being asked to follow a process. Also, it might be

SE2004 Volume 8/23/2004

desirable to follow the exercise or project with a discussion of the usefulness of applying the

particular process. The depth of learning of the process is likely to be considerable, with

relatively little time being taken away from the other material being taught.

Mathematics: Students might deepen and expand their understanding of statistics while

analyzing some data resulting from studies of reliability or performance. Opportunities to

deepen understanding of logic and other branches of discrete mathematics also abound.

Teaching multiple concepts at the same time in this manner can, in fact, help students

appreciate linkages among topics, and can make material more interesting to them. In both

cases, this should lead to better retention of material.

Curriculum Guideline 19: Courses and curricula must be reviewed and updated regularly.

Software engineering is rapidly evolving; hence, most (if not all) courses or curricula can expect,

over time, to become out of date. Institutions and instructors must therefore regularly review

their courses and programs and make whatever changes are necessary. This guideline applies to

curricula or courses developed by individual institutions and faculty. On the other hand,

principles 3 and 4 in section 3.1 require that SE2004 itself acknowledge the rapid evolution of

the field and make necessary changes.

5.5

Concluding Comment

The above represents a set of key guidelines that need to underpin the development of a high-

quality software engineering program. These are not necessarily the only concerns. For each

institution, there are likely to be local and national needs driven by industry, government, etc.

The aspirations of the students themselves also need to be considered. Students must see value in

the education, and they must see it meeting their needs; often this is conditioned by their

achievements (e.g. what they have been able to build) during their program and by their career

aspirations and options. Certainly, they should feel confident about being able to compete

internationally, within the global workforce.

Any software engineering curriculum or syllabus needs to integrate all these various

considerations into a single, coherent program. Ideally, a uniform and consistent ethos should

permeate individual classes and the environment in which the program is delivered. A software

engineering program should instill in the student a set of expectations and values associated with

engineering high-quality software systems.

SE2004 Volume 8/23/2004

Table of Contents: