In the fall of 1996, the Rochester Institute of Technology launched the first undergraduate software engineering program in the United States. The culmination of five years of planning, development, and review, the program was designed from the outset to prepare graduates for professional positions in commercial and industrial software development. From an initial class of 15, the ABET-accredited program has grown steadily over the intervening years until today the student body numbers over 580 undergraduates.

With the continuous growth of cyberinfrastructure throughout modern society, the need for secure computing and communication is more important than ever before. As a result, there is also an increasing need for entry-level developers who are capable of designing and building practical solutions for systems with stringent security requirements. This calls for careful attention to algorithm choice and implementation method, as well as trade-offs between hardware and software implementations. This article describes motivation and efforts taken by three departments at Rochester Institute of Technology (Computer Engineering, Computer Science, and Software Engineering) that were focused on creating a multidisciplinary course that integrates the algorithmic, engineering, and practical aspects of security as exemplified by applied cryptography. In particular, the article presents the structure of this new course, topics covered, lab tools and results from the first two spring quarter offerings in 2011 and 2012.

The questions that are proposed as the basis for academy panel sessions are important ones to ask. In the aggregate, they cover an enormous expanse of the software engineering landscape. The reality of undergraduate computing education is that the vast majority of students do not go through software engineering curricula where there is time to address the academy questions in some depth. Instead, they are in computer science or computer engineering programs, and receive their software engineering education in a single course. What students should really learn in this first, and often only, software engineering course is important because the majority of computing students will not see any other software engineering. The course designer will need to make judicious choices in selecting the material for this course because all of software engineering will not fit in just one course even if you try by using one of the classic software engineering tomes as the textbook. I do not know the right answer to the question I pose in the title of this position paper. I suspect that there is no one set of software engineering topics that should be included, but rather a range of topics to select from based on the purpose and perspective of the course. The answer to this question is important to everyone who has responsibility for providing the software engineering education for the next generation of computing students.

In this panel, we will address questions regarding the development and execution of one type of industry-academic collaboration - corporate-sponsored projects. As representatives of programs at both public and private institutions, we will address a set of questions related to these programs. We have prepared an initial list that will be augmented with questions submitted and voted on by conference participants in advance of the session. After we have presented our prepared responses, the balance of the session will be dedicated to open discussion with audience members.

The ability to work on a team is a paramount skill for every engineer. The capability to understand, identify and work through team problems will significantly enhance the engineer's ability to deliver a high quality product on time and within budget. Far too often, however, the experience of working as a team, with its challenges, is overlooked in the student's education. The Department of Software Engineering at Rochester Institute of Technology introduced an activity in their Freshman Seminar course to help students work in a team-based environment. The specific focus was interacting with problematic team members. This team activity involved student “moles” covertly being inserted to act in a disruptive fashion. At the end of the activity, the teams reassembled to discuss the task the team had been assigned to do. The instructor revealed the role of the “moles” at this point, and the teams discussed the effect their behaviors had on team effectiveness and the strategies used to deal with the disruptive behaviors. The students have praised the activity, finding it to be different, exciting and educational. This paper describes the “mole” activity, our observations of the results, and provides suggestions for future use in coursework.

Student retention is a challenge faced by all engineering programs. Our first year software engineering students have schedules filled with computer science, mathematics, science and humanities. The lack of any exposure to engineering meant some students, expressing a dislike for software engineering, left the program before they had any exposure to the discipline. To address this issue, we created a one credit Software Engineering Freshman Seminar, which all entering students take in their first term at RIT. This lets us insure student/faculty contact early in the program, as well as providing an opportunity to introduce engineering concepts and practices early in each student's program of study. This paper discusses the seminar's current incarnation. In particular, we focus on those aspects of the course which help students identify with software engineering as a profession. The challenge we face is achieving this goal with students whose technical knowledge and skills are modest. We have settled on an approach that provides experience with teamwork, requirements elicitation, and the effects of change, and addressing professional ethics. These in-class activities are complemented by an assignment to interview a practicing software engineer and to write an interview summary for discussion. This activity ensemble serves to disabuse students of the notion that software engineering is little more than programming, or that the discipline is identical to computer science. Should a student exit the program at this point, at least he or she knows a bit about what they are leaving behind.

Camera calibration and the acquisition of Euclidean 3D measurements have so far been considered necessary requirements for overlaying three-dimensional graphical objects with live video. We describe a new approach to video-based augmented reality that avoids both requirements: it does not use any metric information about the calibration parameters of the camera or the 3D locations and dimensions of the environment's objects. The only requirement is the ability to track across frames at least four fiducial points that are specified by the user during system initialization and whose world coordinates are unknown. Our approach is based on the following observation: given a set of four or more noncoplanar 3D points, the projection of all points in the set can be computed as a linear combination of the projections of just four of the points. We exploit this observation by: tracking regions and color fiducial points at frame rate; and representing virtual objects in a non-Euclidean, affine frame of reference that allows their projection to be computed as a linear combination of the projection of the fiducial points. Experimental results on two augmented reality systems, one monitor-based and one head-mounted, demonstrate that the approach is readily implementable, imposes minimal computational and hardware requirements, and generates real-time and accurate video overlays even when the camera parameters vary dynamically.