THE ERR ANT HASHTAG

88 computer Published by the IEEE Computer Society 0018-9162/13/$31.00 © 2013 IEEE

EducATioN

Undergraduate Software Engineering at RIT: Past, Present, and Future

Beginning in 1990, I headed an RIT (Rochester Insti-tute of Technology) faculty team tasked with defining

an undergraduate degree in software engineering. This group’s work led to the 1996 launch of the first software engineering baccalaureate degree in the US. From an initial class of 15, our ABET-accredited program has expanded to include approxi-mately 375 students. Graduates are employed across the spectrum of software development, from retail software firms such as Microsoft and Apple to embedded systems orga-nizations such as UTC Aerospace; many of our graduates have also pursued graduate education in com-puting, engineering, and business.

Why a separate software engi-neering program? Because our personal experience, combined with feedback from our industrial

partners, illuminated a gap between what computer science graduates knew and could do versus what was expected of them in the workplace. Although the theoretical foundations and practical programming skills they possessed were useful, the stu-dents were deficient in areas such as planning and estimating, teamwork, communications, design above the class or function level, testing, ver-sion control, and product release.

Our approach was to create a curriculum addressing these defi-ciencies, better preparing graduates for their careers.

PROGRAM GOALSTeamwork is a key element of

almost all software engineering courses. RIT students make many presentations where they must defend their engineering deci-sions in the face of questions from

faculty and other class members. Project-based courses require team and individual planning, and esti-mating and tracking; students are graded less on their accuracy than on their reflection as to where esti-mates diverged from reality. Design courses evaluate team products less in terms of code per se than on meeting criteria such as low cou-pling, high cohesion, information hiding, and so on.

Of course, software engineer-ing isn’t practiced in a vacuum—it’s always connected to a problem domain. To reinforce this, all of our students must complete a three-course application domain sequence to complement their technical software engineering coursework. Example domains include bioin-formatics, business applications, interactive entertainment, and public policy. Although we recog-

Michael Lutz, Rochester Institute of Technology

The undergraduate software engineering degree program at the Rochester Institute of Technology has encountered numerous challenges in developing a curriculum that bridges the gap between what computer science graduates know and can do versus what is expected of them in the workplace.

February 2013 89

In a similar vein, we have dedicated courses on process and project management, software test-ing, process and product quality, usability engineering, requirements engineering, and software architec-ture. Traditional computer science courses rarely address these topics, yet they’re key elements of a soft-ware engineer’s preparation.

In our capstone course, student teams develop software solutions to real problems provided by internal RIT units, our industrial partners, and various nonprofit organiza-tions. Given their background, team members need little formal instruc-tion, and the faculty’s role is that of advisors and mentors rather than lecturers.

One significant noncurricular aspect of our program is our suite of team rooms. Because we focus on teams in our curriculum, we believe it’s important to provide an envi-ronment conducive to teamwork. To this end, we have 11 designated team rooms, each with a dedicated computer, a projection system, whiteboards, and a table with power outlets for notebooks and laptops. Faculty can reserve rooms for meet-ings during class, but the rooms are otherwise free for use by teams in any software engineering course. This is a better simulation of an

industrial situation with co-located teams and has proven crucial to student growth in leadership and dealing with team dynamics.

EMERGING ISSUESThe future of software engineer-

ing education faces two significant issues: the evolving university-

courses in the second year. The first course is a general intro-

duction to software engineering and is taken by computer science and computer engineering majors as well as those in software engineer-ing. The course uses a team-based, multirelease project as the focal point for introducing the basic issues of team organization, planning, risk management, design quality, unit and functional testing, and docu-mentation. In addition, each team makes two presentations during the term, corresponding to the two time-boxed releases. Given the time available, the topics covered, and the students’ background, the treatment is necessarily cursory. As one stu-dent put it, it’s “the Swiss Army knife of courses.”

The second sophomore course focuses on subsystem design. Although teams design and imple-ment a system in this course, the nature of that system is almost irrel-evant. Our goal is rather to increase the abstraction and complexity students deal with from that of individual classes to a set of classes whose objects collaborate to achieve the system goals.

It’s in this course that we introduce design patterns, primarily to provide a higher-level concept vocabulary for discussing proposed designs and

associated tradeoffs. Although we give brief overviews of specific pat-terns and short lectures on related design topics, most of the class time is devoted to mentoring student teams in an active learning environ-ment. Upon completing this course, students are quite capable of mean-ingful contribution during co-op.

nize that three courses are hardly adequate to introduce a domain, we firmly believe that forming at least one such connection is crucial to students understanding the software engineer’s role.

One aspect of our program that makes our task easier is mandatory cooperative education (or co-op): starting at the end of the second year, every student must alternate one year of paid industrial experience with upper-division academic studies.

For students, co-op provides a way to explore the application of software engineering principles in a variety of settings, as well as to defray some of the costs of attending RIT. For the faculty, however, this means students in upper-division courses no longer need take what they are taught “on faith,” as they bring meaningful work experience into the classroom. It’s much more satisfying to teach students who understand why they’re taking a class and who can relate topics to their co-op experiences.

COURSEWORKOverall, we believe our cur-

riculum’s architecture is sound. Of course, we’ve traded away depth in many areas of concern to computer scientists: we have no required courses on operating systems, data-base theory, algorithmic complexity, artificial intelligence, graphics, or programming languages, although students are free to choose such courses as electives.

We do cover the key engineering concepts from that list via courses in concurrent and distributed systems design, information systems design, and formal (mathematical) model-ing. That is, we’ve changed the focus from the artifacts, such as operating systems, to the essential engineer-ing issues the artifacts expose, such as concurrency control. In so doing, we’ve created space to address other aspects of engineering.

We offer two basic engineering

We’ve changed the focus from the artifacts, such as operating systems, to the essential engineering issues the artifacts expose, such as concurrency control.

EducATioN

90 computer

frequent staged delivery and team reorganization.

In the 1990s, the faculty and RIT as a university believed that the time had come for a dedicated

undergraduate program in software engineering. In essence, we were wagering that students would be attracted to such a program and that industry would eager to employ our graduates. In the intervening years, this wager has paid off handsomely for the program and its students and graduates.

Michael Lutz is a professor of soft-ware engineering at the Rochester Institute of Technology, where he has been a faculty member since 1976. Contact him at mjlvse@rit.edu.

practice, thus compromising the program’s rationale. An encourag-ing development counteracting this trend is the increased funding for empirical research and the develop-ment of sound analysis tools; it’s in these areas that faculty research dovetails with industry needs.

Regarding MOOCs, I won’t address here the many concerns they raise for the viability of tra-ditional colleges and universities; rather, I’ll restrict my comments to the effect on software engineering education.

The largest problem I see is in the area of team-based projects, where the potential advantage of cross-cultural teams is swamped by the dismal rates of course comple-tion. Under these circumstances, at the end of the program, students who do complete the course might be the only remaining members of their original team. Perhaps the only feasible approach in such an environment will be some form of

industry relationship and the challenge of new pedagogical approaches, particularly massive online open courses (MOOCs).

Software engineering is a practi-cal, applied discipline. Research in the field focuses on what engineers do and how they might do it better. Tools such as continuous integra-tion systems, unit and functional test frameworks, version control and configuration management, and formal modeling arise in response to the challenges software engineers face in creating the right product at the right time for the right cost.

One inescapable observation is that most of the tools we use were created in industry, for industry. One reason for this is the lack of respect such pragmatic work is accorded in academic computing, especially regarding tenure and promotion. If faculty members are discour-aged from such work, however, a software engineering program risks diverging too far from industrial

editor: ann e.K. Sobel, Department of computer Science and Software engineering, miami university; sobelae@muohio.edu

Mobile Malware detection, p. 65

developMent tools for sMartphone apps, p. 72

Multitouch interfaces, p. 80

SE

PT

EM

BE

R 2

012

http

://w

ww

.com

pute

r.or

g

ANYTIME, ANYWHERE ACCESS

DIGITAL MAGAZINESKeep up on the latest tech innovations with new digital maga-zines from the IEEE Computer Society. At more than 65% off regular print prices, there has never been a better time to try one. Our industry experts will keep you informed. Digital magazines are:

• Easy to Save. Easy to Search.• Email noti� cation. Receive an alert as soon as each digi-

tal magazine is available. • Two formats. Choose the enhanced PDF version OR the

web browser-based version.• Quick access. Download the full issue in a � ash.• Convenience. Read your digital magazine anytime, any-

where—on your laptop, iPad, or other mobile device.• Digital archives. Subscribers can access the digital issues

archive dating back to January 2007.

Interested? Go to www.computer.org/digitalmagazines to subscribe and see sample articles.