ZeePedia buy college essays online

Software Engineering - II

<<< Previous Guidelines for SE Curriculum Design and Delivery Next >>>
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.
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
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
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.
Guidelines for Constructing the Curriculum
Curriculum Guideline 2: Curriculum designers and instructors must think in terms of
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.
Attributes and Attitudes that should Pervade the Curriculum and its
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
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
Curriculum Guideline 9: Students should be instilled with the ability and eagerness to
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
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
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.
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.
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