Content uploaded by Jeff Offutt
Author content
All content in this area was uploaded by Jeff Offutt on Jul 03, 2014
Content may be subject to copyright.
96 IEEE SoftwarE | publIShEd by thE IE EE comput Er SocIE ty 0740 -7459 /13/ $ 31.0 0 © 2 013 I EE E
Editor: Neil Maiden
City Un iversit y London,
n.a.m.maiden@city.ac.uk
Editor: Philippe Kruchten
University of British Columbia
pbk@e ce.ubc.ca
Sounding Board
I RECENTLY READ a paper about software en-
gineering research,1 and once again discovered
that its author, Lionel Briand, had published
“my” ideas before I wrote them. Thankfully,
his writing often stimulates further think-
ing, and this was no exception. His visionary
thoughts on software engineering research
started me thinking, but in terms of software
engineering education rather than research.
Briand wrote about the “paradox of be-
ing both highly relevant and increasingly un-
derfunded and discredited.” Personally, I’ve
found that software engineering research
gets more respect every year, although the
funding is abysmally low, at least in the US.
This article argues that software engineering
is not given enough relevance or support in
higher education.
Research and Education
I’ve been a researcher in software engineer-
ing for more than 25 years, but I’ve also been
an educator. I taught my rst software engi-
neering course as a graduate student in 1985,
a standard undergraduate survey course. I
joined my current university, George Ma-
son, in 1992, partly because it had a full
MS program in software engineering that
was distinct from computer science. I’ve led
this large successful program since 2003 and
helped create software engineering concen-
trations in our PhD program (2000) and in
our undergraduate applied computer science
program (2010). Along the way, I’ve cre-
ated over a dozen new software engineer-
ing courses, many of which had never been
taught anywhere and had to be designed
without adequate textbooks or other mate-
rials. This wealth of experience in software
engineering education lets me see things dif-
ferently from many of my colleagues.
Briand wrote a sentence that I’ve said
many times: “Software engineering isn’t a
branch of computer science; it’s an engineer-
ing discipline relying in part on computer sci-
ence, in the same way that mechanical engi-
neering relies on physics.”
Some of my colleagues respond by say-
ing, “Well, of course,” but many traditional
CS professors think it’s almost heretical. In
this old-fashioned view, software engineer-
ing has always been part of computer science
and always will be. But things change. This
analogy has been 100 percent convincing to
my colleagues in civil engineering, electrical
engineering, and other traditional engineer-
ing disciplines.
Differentiating Software Engineering
from Computer Science
If software engineering isn’t a branch of
computer science, then we must ask prac-
ticing software engineers what they need to
know that they don’t learn as part of CS de-
grees. Most computer science undergradu-
ate students take one software engineering
class, typically with a week or two spent on
each phase in the traditional waterfall life-
cycle model. A lot of the semester is devoted
to process theory. It’s worth noting that in
modern software engineering projects, the
Putting the Engineering
into Software Engineering
Education
Jeff Offutt
continued on p. 94
94 IEEE SoftwarE | www.computEr.org/SoftwarE
Sounding Board
traditional waterfall model is almost
never used, and the ideas about pro-
cess change constantly—often much
faster than textbooks or instructors’
knowledge. Moreover, as David Par-
nas asserts, process must be shown, not
taught, by mentoring young engineers
through actual projects.2
This answers what CS students learn
about software engineering, but what
useful knowledge are they not learning?
It turns out that this is an easy question
with lots of answers: usability, testing,
security, design modeling, project man-
agement, quality control, standards,
architecture, embedded applications,
evolution, Web applications, ethics, and
so on. The list constantly changes. Yes,
CS students learn a little about some of
these topics—for example, they spend
about one week on testing in a semester-
long class. But is a week really enough
for an activity that consumes well over
50 percent of the effort in large soft-
ware engineering projects?3
I like to ask my students a question:
What is your expected job title when
you graduate? If they know anything
about the computing eld, they don’t say
“computer scientist.” Most answer cor-
rectly, “software engineer.” Isn’t it just
a little strange that we prepare software
engineers by teaching them computer
science? This fact alone should obviously
imply that we either need computer sci-
ence programs to include more software
engineering or more software engineer-
ing degrees. After all, nobody would
argue that students study physics to be-
come mechanical engineers!
Although both approaches would be
an improvement, I believe that CS edu-
cation shouldn’t change to include more
software engineering. Rather, I agree
that they should continue to diverge.
Software Engineering Is
Engineering, Not Science
Can you imagine mechanical engineer-
ing being part of physics? Can you
imagine ME faculty performing re-
search within the physics department?
Can you imagine an ME program our-
ishing within the connes of a physics
department? You probably can’t, but
that’s where it originated.
Over a century ago, universities
had some departments and programs
in physics that taught really practical
applications in physics, such as how
to use principles from physics to build
bridges, dams, cars, airplanes, and
electrical circuits. Over time, phys-
ics ssioned into elds now known as
mechanical engineering, civil engineer-
ing, electrical engineering, mining engi-
neering, aerospace engineering, and a
host of others. The process continues,
but from our 21st-century perspec-
tive, it’s now obvious that engineering
elds are different pedagogically and
should be taught differently from phys-
ics. It’s equally obvious that the hun-
dreds of thousands of engineering stu-
dents should take three or four courses
in physics and even more in math. This
is why my employer, George Mason
University, has a successful and long-
lasting MS program in software engi-
neering and, more recently, a BS con-
centration in software engineering.
So how exactly does software edu-
cation differ from computer science
education? The most obvious is in top-
ics; the list in the earlier paragraph is
much of what we should teach in soft-
ware engineering programs. Software
engineering education also must focus
on multiple quality attributes—not just
efciency, but reliability, scalability, se-
curity, availability, maintainability, and
usability. Good engineering is also about
making the right tradeoffs based on
contextual requirements, which CS stu-
dents aren’t taught. Parnas emphasized
that engineering students should learn
applications and how to build complete
products, as opposed to how to conrm
known facts and extend knowledge.2
Another aspect that differentiates
software engineering is that it needs
to include noncomputing topics other
than CS. Software is part of larger sys-
tems, so we need systems engineering.
Software is developed by teams, so we
need project management. Software
must be high quality, so we need statis-
tical quality control. Deeper differences
can affect not just what we teach but
how we teach. Traditional CS courses
emphasize single solutions, developed
by students working alone, and evalu-
ated primarily by efciency. This ap-
proach doesn’t work for engineering.
Three Principles for Teaching
Software Engineering
Computer science, with its strong roots
in mathematics, is usually taught using
“convergent thinking,” meaning prob-
lems have one answer and successful stu-
dents should tend toward that answer.
Engineering, however, especially soft-
ware engineering, needs divergent think-
ing, where multiple answers are possible
and the most successful students should
continued from p. 96
Process must be shown,
not taught, by mentoring young
engineers through actual projects.
January/fEbruary 2013 | IEEE SoftwarE
95
Sounding Board
nd a solution that’s unique from other
students’ solutions. Divergent thinking
is encouraged by assigning problems
that have many solutions.
In CS, traditionalists become ada-
mant supporters of “individual learn-
ing,” discouraging cooperation at all
costs. This is partly because instructors
worry about plagiarism—not surpris-
ing since computers make it so very easy
to copy. Thus, a side effect of spending
so much energy discouraging cheating
is that we alienate the educational, em-
powering benets of collaboration and
social processes. Practical software en-
gineering is an extremely collaborative
discipline, and I’ve found that software
engineering students are best taught
with collaborative learning. Students
should be encouraged to work together,
to solve problems together, and to learn
together. Instead of focusing exclusively
on discouraging plagiarism, we should
encourage students to learn more by
learning together. Students learn more
through collaboration than competition!
Computer science projects and home-
work assignments tend to be assessed
on a uniform scale that measures every
student’s work with the same yardstick.
But in engineering, especially software
engineering, the notion of what will suc-
ceed often varies depending on the con-
text, including users, market, platform,
and release date. This suggests that we,
as educators, should use differentiated
assessments. Instead of every student
trying to accumulate exactly the same
points for the same requirements, we
could offer a menu of potential features
and attributes for students to choose
from, each of which accumulates some
number of points.
Clearly, if software engineer-
ing is really the “best job,”4
and employment is continuing
to increase throughout the great reces-
sion with no end in sight, universities
must shift from a computer “science”
focus to a software engineering focus.
Universities should create more under-
graduate software engineering degrees.
If that’s not possible, undergraduate CS
programs should add more software
engineering—a one-semester course is
clearly insufcient. Physics is still go-
ing strong, and society still needs physi-
cists. But what’s the ratio of engineers
to physicists—100 to 1? 1,000 to 1?
Also, when we teach software engi-
neering, we must remember that diver-
gent thinking and collaborative learning
are essential abilities for practicing en-
gineers, and differentiated assessment is
essential for teaching software engineer-
ing. I’ve successfully used all of these
techniques in my classes, and so can
you. As software engineering continues
to move out of the shadow of CS to es-
tablish itself as a separate, independent
discipline, industry will be more satis-
ed with our graduates, and companies
will create more high-quality software.
Don’t we owe this to society?
Acknowledgments
I’m grateful to Lionel Briand, R ich LeBlanc,
Paul Ammann, and Stephanie Offutt for
helping me rene my thinking on this topic.
References
1. L. Briand, “Embracing the Engineering Side of
Software Eng ineer ing,” IEEE Software, vol.
29, no. 4, 2012, pp. 93–96 .
2. D. Parnas, “Software Engineering Progra ms
Are Not Computer Sc ience Programs,” IEEE
Software, vol. 16, no. 6, 1999, pp. 19–30.
3. B. Boehm, Software Engineering Economics,
Prentice-Hall, 1981.
4. Y. Klugerm an, “Softwa re Engi neer Ranked
Best Job for 2011,” Brain Track, Jan. 2011;
www.braintrack.com/college-and-work-news/
articles/software-engineer-ranked-best-job
-for-2 011-11010502.
JEFF OFFUTT is professor and director of the
software engineering M S program at George Mason
Universit y. He received the Best Teacher Award from
GMU’s Volgenau S chool of Engineering in 2003 and
coauthored the textbook Introduction to Software
Testing (Cambridge University Press, 2008). Offut t
is co-editor in chief of Wiley’s Software Testing,
Verication, and Reliability and one of the founders
of the IEEE International Conference on Software
Testing, Verication, and Validation. Contact him at
offutt@gmu.edu.
IEEE Software (ISSN 0740 -7459) is published bi monthly by the IE EE Computer So-
ciety. IEEE headquarters: Th ree Park Ave., 17th Floor, New York, N Y 10016-5997.
IEE E Computer Soci ety Publicat ions Ofce: 10 662 Los Vaqueros Cir., L os Alamitos ,
CA 90720; +1 714 821 8380; fax +1 714 821 4010. IEEE Computer Society head-
quart ers: 2001 L St., Ste . 700, Washington , DC 20036. Subscription rates: IE EE
Computer S ociet y members get the lowest rate of US$56 per yea r, which includes
printed issues plu s online acces s to all issues publi shed since 1984. Go to www.com -
puter.org /subscribe to order a nd for more informat ion on other subscription prices.
Back iss ues: $20 for membe rs, $209.17 for nonmembe rs (plus shipping a nd handlin g).
Postmaster: Send undelivered copie s and address changes to IE EE Software, Mem-
bership Proces sing Dept., IE EE Ser vice C enter, 445 Hoes Lane, Piscataway, NJ
08854-4141. Periodic als Post age Paid at Ne w York, NY, and at additional m ail-
ing of ces. Ca nadia n GST #12 5634188. Canada Post Publications Mail Agreement
Number 4 0013885. Re turn undeliverable Canadian addresses to PO Box 12 2, Ni-
agara Falls, ON L 2E 6S8 , Canada. Print ed in the U SA.
Reuse Ri ghts and Repri nt Perm issions: Educational or personal u se of thi s ma-
terial is permitted without fee , provided such use: 1) is not m ade for prot; 2)
includes this not ice and a f ull cit ation to the original work on the rst page of
the copy; a nd 3) does not i mply IEEE endors ement of any t hird- part y product s or
services. Aut hors and their compa nies a re permitted to post the accepted version
of IEE E-c opyrig hted material on their own webservers without permission, pro -
vided th at the IEE E copyright not ice and a full c itation to the orig inal work appe ar
on the r st screen of the pos ted copy. An accepted manuscr ipt is a version which
has been revise d by the author to incor porate review sug gestions, but not the pub-
lished version wit h copyedit ing, pro ofreading, and formatting adde d by IEE E.
For more in formation, please go to: http://w ww.ieee.org/publicat ions_sta ndards /
publications /rights/paperversionpolicy.html. Permission to reprint/republish this
material for commercial , advertising, or promotion al purp oses or for creating
new colle ctive work s for resale or redistribut ion must be obtaine d from IE EE by
writi ng to the I EEE I ntellectual Property Rig hts Ofce, 445 Hoes La ne, Pisca-
taway, NJ 08854 -4141 or pubs-p ermissions@ ieee.org. Copyright © 2013 I EEE .
All rights res erved.
Abstracting and Library Us e: Abstracting is perm itted w ith cred it to the sou rce. Li -
brarie s are permitted to photocopy for private use of patrons, provide d the per-copy
fee indicated in the code at t he bottom of the rst page is pa id through the Copyright
Clearance Center, 222 Ro sewood Drive, Danvers, M A 01923.
